kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 3/20/2019 3:04 PM, John Beard wrote:
> On Wed, Mar 20, 2019 at 6:44 PM Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> 
>> It looked like in the example that Brian posted the indent was more than
>> eight spaces but that may have been a font spacing issue.  I'm fine with
>> eight spaces as the continuation indent.
> 
> Hmm, you're right, I didn't notice that. It seems clang-format
> "compensates" for the alignment of other declarations in the block:
> 
> static LIB_TEXT*               loadText( std::unique_ptr<LIB_PART>&
> aPart, LINE_READER& aReader,
>                       int aMajorVersion, int aMinorVersion );
> static LIB_RECTANGLE_but_long* loadRectangle( std::unique_ptr<LIB_PART>& aPart,
>         LINE_READER& aReader, int aMajorVersion, int aMinorVersion );
> 
> I'm not sure why this is, or if it's by bug or design in clang-format.
> 
> However, this does only happen when you have declarations with no
> spaces between then. Adding newlines gets:
> 
> static LIB_TEXT* loadText( std::unique_ptr<LIB_PART>& aPart,
> LINE_READER& aReader,
>         int aMajorVersion, int aMinorVersion );
> 
> static LIB_RECTANGLE_but_long* loadRectangle( std::unique_ptr<LIB_PART>& aPart,
>         LINE_READER& aReader, int aMajorVersion, int aMinorVersion );
> 
> The coding policy specifies 1 line spacing above declarations with
> Doxygen comments, and 2 above "bare" declarations like these. So this
> bug/quirk/feature should rarely be encountered. So the original code
> here is wrong.
> 
> Of course, it always pays to be careful with the auto-formatter - I
> normally get the editor to do most of it, and then manually check
> changes with "git clang-format --diff" if I get a commit failure for
> formatting. Normally a botched space-in-parens, for me!

The moral of the story is "never trust the auto-formatter".  Sounds
suspiciously like "never trust the auto-router" :)

> 
> Cheers,
> 
> John
>