[Bug-indent] My indent notes

[Roger Flores]

Hi.  I'd first like to say a great thanks for indent.  It really helps 
keep code worked on by
multiple people more consistent!

I've made a list of things I noticed on my latest project.  I've 
organized the list into
what I'll call bugs, followed by what I'll call features, because they 
support our style better.



* function definitions vs. declarations

The "-bdfa" options is great for giving room to comment each function 
argument.  But
I don't document both the declaration and the definition.  it would be 
great to
collapse the declaration to avoid wasting vertical space.


  extern void foo(int a,
     int b,
     int c);
  extern void foo(int a,
     int b,
     int c)
  {
  }
 
  vs.
 
  extern void foo(int a, int b, int c);
  extern void foo(int a,
     int b,
     int c)
  {
  }
 
* static initalized array indentation.

There doesn't seem to be a way to get the "{" to the start of the next line.

static int command_key[key_count] = {
  'K', 'L', 'J', 'H', 'k', 'l', 'j', 'h',
 
vs.
 
static int command_key[key_count] =
{
  'K', 'L', 'J', 'H', 'k', 'l', 'j', 'h',
 
 

* typdef names

I get the following.

typedef struct
{
  StatusType status;
}
SomePreferenceType;


I'm kind of mixed.  We've always placed the name after the '}', not on 
the next line.
On the other hand, this style is more consistent with how our do while 
loops.


* function args should increase indentation

When the arguments to a function are wrapped the next line, they should 
be indented more.
This example uses "-nlp".  Note that this seems to happens for 
conditions in if statements.

        PictureWindow[i] =
           CreateOffscreenWindow(PictureBitmapPtr[i]->width, 
PictureBitmapPtr[i]->height,
           screenFormat, &error);


  if (Foo(aaaaaaaaaaa, &bbbbbbbbbbb, ccccccccc, ddddddddd, eeeeeeee,
        &fffffff, &gggggggg) != 0)
  {

The first example seems wrong because the last line, which is within a 
function arg list, should
be indented more. The second example's second line appears to be 
indented twice, which
seems right.
 
* poor line breaking

I notice indent, when an assignment is too long, breaks the right side 
to the next
line.  But this doesn't guarantee that the right side will fit on one 
line.  When the
right side will not fit, I'd prefer it to start wrapping the right side 
on the line
with the left side.

        seconds =
           (aaaaaaaaaaaaaaaaaaaaaaaaa + (Foo() -
              bbbbbbbbbbbbbbbbbbbb)) / ccccccccccccccccc;

vs.

           seconds = (aaaaaaaaaaaaaaaaaaaaaaaaa + (Foo() -
               bbbbbbbbbbbbbbbbbbbb)) / ccccccccccccccccc;

or even better because of parentheses

           seconds = (aaaaaaaaaaaaaaaaaaaaaaaaa +
               (Foo() - bbbbbbbbbbbbbbbbbbbb)) / ccccccccccccccccc;




* pointer declaration spacing

Pointers in a function argument have a space before and after the 
asterick, but pointers in
structures and declarations are different.  They should be consistent.

extern sometype * (sometype * a)
{
   sometype *b;
}



Features

* blank lines after declarations

I like to separate out variable declarations better with more vertical 
whitespace.  Changing
"-bad" to take a number "-bad(n)", would be perfect.  It defaults to one 
currently.  I want
to set it to two.


* blank lines after procedures

I like to separate out procedures better with more vertical whitespace.  
Changing
"-bap" to take a number "-bap(n)", would be perfect.  It defaults to one 
currently.


* change comment type

I often move code from C to C++.  An option to convert comment types 
from "/* */" to "//"
would work wonders for consistency of the new code.  It may be important 
to treat
indented comments differently than comments starting in column 0.  Most 
column 0 comments
I see are file or function descriptions.


* Long conditions

Long conditions are inherently hard to read.  Squishing them into as few 
vertical lines
as possible simply increases the reading difficulty.  When a condition 
cannot fit
on one line, there should be an option that splits the condition at the 
highest precedence
operator, one line per split.  Do this recursively on each split.

if (a == 1 && b == 2)

if (aaaaaaaaaaa == 1 &&
   bbbbbbbbbbbbb == 2 &&
   ccccccccccccc == 3)
  
if (aaaaaaaaaaa == 1 &&
   (xxxxxxxxxxxx == a || yyyyyyyyyyy == a) &&
   ccccccccccccc == 3)
  
if (aaaaaaaaaaa == 1 &&
   (wwwwwwwwwwwwwwwwww == a ||
       xxxxxxxxxxxxxxxxx == a ||
       yyyyyyyyyyyyyyyyy == a ||
       zzzzzzzzzzz == a) &&
   ccccccccccccc == 3)
  
Ideally allow an option to force conditions with more than one part to 
split.  This could be
a --dont-cuddle-condition option.


-Roger Flores