C definition formatting question

Question

I am thinking about changing my formatting style. I have been doing this:

char *foo(IULabel *label, char *buffer) {
    UITextView  *tv;
    int         i;
    int         *j;

...
}

and I am thinking that it might be easier to understand if I were to write:

char * foo(IULabel * label, char * buffer) {
    UITextView *    tv;
    int             i;
    int *           j;

...
}

or

char* foo(IULabel* label, char* buffer) {
    UITextView*    tv;
    int             i;
    int*            j;

...
}

How do you do it?

Answer 1

Coding style is completely subjective, but I like this:

char* foo = "Foo";

It makes more sense to me because the type is *pointer to char", so it seems natural that the pointer notation would appear next to the type specifier.

EDIT: And I think that stephentyrone is probably correct in his assumption.

Answer 2

A professor once told me in university "the most important rule of style of consistency." As long as you are doing the same thing everywhere, it doesn't matter. If you are the only one working on the project, do whatever looks best to you. Otherwise bring it up with the other devs, form a consensus and work with that.

Answer 3

Most C programmers I know write:

int *x;

Most C++ programmers I know write:

int* x;

I attribute this to the fact that C programmers think of x as "a pointer to a chunk of memory that is to be interpreted as an int", whereas C++ programmers think of x more as "an object of type int*"

I'm an assembly programmer, but I like the first style.

Answer 4

It depends on whether language im using, also on the IDE automatic capabilities.

In C# I dont align line endings, as there is comments separating declarations.

But in VHDL where declarations are common and represent wiring I prefer to align line endings like your 2nd format.

Give it a try and see which one will be more comfortable and time saving.

Answer 5

I use the style:

char *x;

because this logically reflects how C parses declarations - the "definition follows use" rule. Don't think "x is a char *", think "*x is a char".

That lets you correctly parse definitions such as these:

const char *x;

(*x is a const char)

char * const x;

(x, constant, after applying * is a char)

char *x, y, **z;

(*x is a char, y is a char, **z is a char)

Addendum:

Responding to a couple of the comments...

The idea that declarations can be written as TYPE LABEL; ends up breaking down for more complex types, even if you ban multiple declarations on one line (which I don't agree with, either: int i, j; has always been idiomatic C). For example, if I want to declare x as "pointer to array of 10 char", then the type is char (*)[10] (this is how you'd write it in a cast, for example). But you can't use the TYPE LABEL; pattern:

char (*)[10] x;    /* Not valid C :( */

Function pointers are another example. The usual rejoinder at this point is "Always use a typedef for complex types like that!", and here I feel we must simply part ways and agree to disagree. Either you consider the logical inconsistencies and restrictions ("declare only one variable per line", "always build up complex types from simple typedefs") an appropriate price to pay for making declarations look the way you feel they should, or you don't.

In response to the Stroustrup comment I note that K&R uses the char *x style, and here it seems we have the root of the C / C++ divergence on this matter of style.

Answer 6

Your first one will lead to less confusion. Otherwise:

int* x, y;

At first glance, they appear to be the same type, but they're not. The first is a pointer-to-int, and the second is int. This is much clearer:

int *x, y;

Answer 7

I think this is surely subjective, but if i were to align up the names, then i would put the modifiers directly next to them and align the names directly

char *foo(IULabel *label, char *buffer) {
  UITextView *tv;
  int         i;
  int        *j;

  ...
}

But usually, i just do

char *foo(IULabel *label, char *buffer) {
  int i;
  int *j;
  UITextView *tv;
  ...
}

I try to order things from "short lines" to "long lines", if the order wouldn't matter otherwise :)

Answer 8

One of the downsides to formats like this:

UITextView *tv;
int         i;
int        *j;

is that someday you'll need to add another variable whose type has more characters than UITextview :

UITextView *tv;
int         i;
int        *j;
SomeOtherDataType t;

which presents you with the choice of either messing up the column layout and leaving a broken window¹, or adding spaces to the other variables and committing the revision-control atrocity of Introducing Unnecessary Reformatting that Obscures the Material Changes.

My preference is to declare variables one per line, ordered by type when it makes sense, and sacrifice some vertical space in favor of readability and ease of commenting:

UITextView
   *tv;         // Data to be edited by the user.
int
    i,          // One-based index (for compatibility with BASIC)
   *j;          // Will be malloc'ed -- free it later.
SomeOtherDataType
    t;          // See p. 23 of req'ts doc for details.

I'm not completely satisfied with this, however, and would be interested to see additional solutions. What are yours?

---

¹ I'd be remiss if I didn't mention that the entire article is quoted here. Where's that $20 you owe me, Jeff? :-)