georgef on Source Code Typography

When I first started programming in C, I did the same thing with pointers (i.e.,

    char* str;

instead of

    char *str;

Unfortunately, this creates the wrong impression that

    char* str1, str2;

creates two pointer-to-char variables, whereas actually str1 is a char pointer and str2 is simply a char. Indeed, I was confused on this point myself when I was a newbie, which led to great confusion later on.

The clearest way I've ever found to think about C declarations (ironically, I think I read this in some article maligning C's syntax in favor of Go's), is that each declaration is of the format

    [type] [expressions--one for each new variable--that equate to type];

Thus, the way I think of declaring a char pointer is

    char [de-referencing the variable (which is a char pointer) to arrive at the char];
    char *str;

(Obviously, not everyone is going to agree that that is simple, but it works for me and my brain.)

Anyway, the point is that while typography is great, it can be just as harmful as helpful if you communicate the wrong impression to the reader. And to be fair, it really looks like the author is not at home in C: besides his misconception about pointer declaration, he didn't bat an eye at the old-style argument-declaration syntax that has been obsolete since ANSI C.

Also, I hope I never write a for loop that looks so massively bloated--a matter of opinion I guess.

dsego 13y

What is wrong with having str1 and str2 declared on separate lines? Like this:

  char* str1;
  char* str2;

What is gained with combining these declarations (except for less typing)?

georgef 13y

Less typing is exactly the benefit, and with it less chance of error because of less repeated code. It is also another way of showing parallelism in your code.

And again, the wrong impression is conveyed (that you are declaring a variable of type char* instead of a pointer type that dereferences to a char).

With more complex types, not understanding what is really going on makes code incredibly opaque (and that typographical style ad hoc). What would you do with this:

    char *((*func)(char *));

That isn't a char pointer at all. It's a pointer to a function that takes a char pointer as an argument and returns (i.e., evaluates to) a char pointer. It looks incredibly dense (to me, at least), unless I think of it in the way I talked about above (in which case it all makes sense and is kind of cool).

With the convention used in the article, the declaration would be something like this:

    char* ((* func)(char*));

Which doesn't make clear why the outside parentheses are needed, or why there is a dereference (or multiplication?) operator in front of the variable name.

The idea of a variable declaration being an expression that evaluates to a basic type is actually the reason why the same symbol * is used in the declaration and in the dereferencing of pointers: they mean the same thing.

Basically, what I am trying to say is that the typographical practice used in the article is at odds with the actual meaning of the statement (and the explanation he gives shows he clearly does misunderstand the statement), which can only lead to confusion in the long run, especially when you encounter code written by other people. Or, as with your example, it can lead to eschewing a useful feature of a language simply because it doesn't look pretty according to your arbitrary whitespace conventions.

limmeau 13y

Grouping comes to mind, e.g.

        int x, y;
        int width, height;
        int area;
        int numPoints;

_mpu 13y

Less typing, less lines, more information on the screen and the readability is not impaired.

Comments