Title: You Write, the Editor Replies

Hi Francis,

I had a few comments scribbled whilst reading recent issues of C Vu, but I have only just had a chance to email them to you, so some are now rather late.

(1) Pre-increment Operators

In Code Review - A Big Number class (C Vu 11.4, p 41), the Harpist's comment on the pre- and post-increment operators was just "Fine." Should the pre-increment ones return non-const references rather than values? I think I have always written mine that way, and I think they need to conform to the expected "C-style" operator semantics.

I took a few moments to think about that, and I think not unless you believe that (i++) = 4; should work. By returning a value the compiler will reject such silly code. Returning a non-const reference might just surprise a programmer with an unexpected rejection of code but returning such does not seem to add anything worthwhile. I suspect that it should return a const reference. What do others think?

(2) Code Legibility

(Even longer ago), Silas commented (in C Vu 11.2, p 26) on the placement of * and & in declarations. I know this topic verges on the religious, but for the longest time I preferred K&R style placement - i.e. with the variable as char *pc rather than char* pc

for one simple reason: The human eye/brain (mine, anyway!) pays more attention to the start of words than the end, particularly for English nouns that rarely inflect. When reading quickly, one tends to glance at the start of each word and try to interpret it as quickly as possible before moving on to the next. My note-taking sometimes uses this fact - when writing fast, suffices like "ing", "tion", and so forth end up as squiggles, but the meaning is often not lost and I can read my notes quite quickly and effectively based on the starts of the words. Nouns are often used for the names of classes, and once you are familiar with the names of your classes, you tend to identify them quickly, paying most attention to how they start. As a result, I find I can read code much more easily and quickly if the often important pointer or reference or whatever stands out at the start of the variable name, rather than getting lost at the end of the type. In the following example, my eye initially breaks up the code:

VeryLongClassName& function(AnotherName* a);

as a type on the left, a function name, another type and the variable name, a. Unless I look carefully at each type, it is harder to decipher them. Putting the &s and *s at the start of the variable makes them much more visible (for me), because they are at the start of the runs of characters:

VeryLongClassName &function(AnotherName *a);

This my eye breaks up as a type name, a function name beginning with an ampersand, another type and a variable beginning with an asterisk. Unless I do this, I find the & and * tend to blend in to the preceding word so you miss it. Furthermore, a lot of the code I see and deal with tends to have multiple variable declarations on a line, so the usual problems of typing

char*  a, b;

rear their heads.

More recently, though, I have tried switching to the "space-both-sides" version, and I like the way it makes the * or & stand out even further, giving the readability that I appreciated with my old method. It makes you stop and think.

VeryLongClassName & function(AnotherName * a);

The only drawback is that, to the uninitiated, these may appear more similar to the binary & and * operators, and so possibly lead to initial confusion.

The fact that the start of words are so important is another nail in the coffin for long-winded Hungarian prefixes. When you look at something like "m_lpszName", you have to wade through 60% of the word before you reach the purpose of the variable (a name). I still like and use simple "m_" and "s_" scope prefixes, and the underscores here help you see the start of the real variable name, but multi-character type encoding ("lpsz", etc.) slows down your reading of the code.