[Toybox] [PATCH] Fix dmesg -c and -C.

[Rob Landley]

On 01/04/2017 03:46 PM, enh wrote:
> On Wed, Jan 4, 2017 at 1:28 PM, Rob Landley <rob at landley.net> wrote:
>> On 01/04/2017 01:08 PM, enh wrote:
>>> Also fix some of the formatting I introduced earlier. (A clang-format file
>>> would help prevent these mistakes...)
>>
>> I dunno clang-format. Is it similar to lindent?
>>
>>   https://github.com/torvalds/linux/blob/master/scripts/Lindent
>>   https://www.freebsd.org/cgi/man.cgi?query=indent
>>
>> (This is a thing I'm aware of, but have not personally found useful.
>> Fixing up whitespace is one of the things I do during cleanup passes. :)
> 
> no, http://clang.llvm.org/docs/ClangFormat.html is a source
> reformatter based on the clang parser. if your project adheres to
> chromium style, say, you just say --style=Chromium and it means
> changes look the same, no matter who submits them.

So different implementation, but conceptually similar to lindent, as in
"large group of guys supply a tool to reformat source in their house
style, but using it to police a different style is nonobvious".

> you can have a
> .clang-format file in your project to configure the formatting to
> whatever your project's style actually is
> (http://clang.llvm.org/docs/ClangFormatStyleOptions.html).

Twenty page-downs of text. Configuration file in "YAML" format,
configuration file can hold multiple languages, distinguished by file
extension. Parses magic comments. 74 alphabetical options each of which
I must individually set to define a format.

Can AlignAfterOpenBracket be condtional? For if statements I put the
curly bracket on the same line if it fits in 80 chars, cheat and put it
on the next line if that would make it fit in 80 characters, but if the
if line itself winds up breaking to multiple characters I put the
opening curly racket on its own line left aligned with the if (so it's
easy to tell at a glance where to divide the test and the body). That's
potentially automatable (I could do it in python) but I don't know the
config option to tell this thing I do that.

For the AlignOperands example I'll sometimes indent them like that if
they're a large calculation assigned during the declaration wraps, but
only if the variable is declared by itself; if the declaration includes
multiple variables I indent two spaces. (And am likely to move the
assignment out of the declaration.)

Sometimes I cheat and go:

  for (i=0; i<blah; i++) if (walrus(i)) {
    lots of lines here;
  }

To avoid having a large inner block indented a second level. I could
come up with a heuristic of how many lines of body make that sort of
thing worthwhile, but that raises the possibility that a patch adding
one line could reindent a larger section, when I'm more likely to
grandfather in the older indentation to avoid churn unless I'm doing a
dedicated cleanup pass. (You can have more churn when behavior doesn't
(intentionally) change.)

For wrapped run on lines, I usually indent a single additional line by
two spaces (especially if that's the only way it fits in 80 chars
without breaking) but I'm more likely to indent multiple run-on lines to
the open parentheses of the function or statement (to avoid the "do I
indent the third line by _another_ two spaces" issue), except if the
open parentheses is far enough to the right that indenting by two spaces
instead saves me a line. (And sometimes I indent to the open parentheses
anyway if the indentation of the first line isn't something you can tell
at a glance because the lines before and after it vary too much and
indenting the same mount for _different_reasons_ could lead to confusion.)

Oh, and every once in a while, to make something fit in 80 chars, I'll
take out a space or two after a comma in function arguments. Yeah,
that's bad cheating but it saves a line wrap!

I honestly don't expect most people to pick up on this. I'm just trying
to make the code easy to read and vaguely consistent.

> certainly
> means contributors don't have to think "would rob have spaces here or
> not?".

I try not to beat up on people about whitespace. (The "int* a;" thing is
a pet peeve of mine because it indicates they don't know what the code
they're writing _means_. Otherwise it's no different from "assignments
have space around the =, comparisons don't" which I had drilled into my
head by Erik Andersen on busybox (he cared about it a _lot_ more than I
did, dunno why) and wound up in the habit of doing and now I just try to
be consistent about it. I'm aware that I sometimes put spaces around
comparisons or "blah & FLAG" when _consistency_ says I shouldn't (pick
one and stick with it). I try to get it consistent in new code for but
going through and changing old code for just that isn't worth the churn.)


Rob