[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-indent] My indent notes

From: Roger Flores
Subject: [Bug-indent] My indent notes
Date: Fri, 10 May 2002 19:20:50 -0700
User-agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.0rc1) Gecko/20020417

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;

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;


           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;


* 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]