What does style look like, part 6

re: What does style look like, part 6

Mike Dunn — Tue, 16 Nov 2004 20:22:00 GMT

"good names describe semantics, not type" [and therefore do not use Hungarian]

*sigh* Where to start with that one...

re: What does style look like, part 6

Larry Osterman — Tue, 16 Nov 2004 20:23:00 GMT

Mike, I'm just the messenger :)

I agree with the comment otoh - good variable names SHOULD describe semantics.

re: What does style look like, part 6

damien morton — Tue, 16 Nov 2004 20:26:00 GMT

Everyone pooh poohs Pascal, but Wirth got a lot right. I would say that Java and C# owe more to Pascal, in some ways, than to C.

re: What does style look like, part 6

Eric Newton — Tue, 16 Nov 2004 21:07:00 GMT

I didnt see the part of the CLR guidelines that discourages prefixes for member variables, and if so, that's stupid.

There should be a differentiation between member variables, parameters and local variables, if desired.

I typically prefix member variables with the "_" underscore prefix, and to some degree I also qualify references with "this" so you'd see in my code

"this._name = value;"
"this._id = value;"

The added benefit is intellisense once you type "this._" you see all your class member variables lined up. Why this is explicitly discouraged in the CLR guidelines is dumb, and goes against what Microsoft's own programmers apply to a good 75% of the classes.

Additionally, related to naming conventions/clashes with member variable names/etc, I have a problem with people writing methods that are more than 10-20 lines.

IMO, If you have a function with 15 local variables, (which incidentally slows down CLR efficiency, I hear because of certain IL instructions are optimized for the first 5 locals), then you've got a function that is too broad in scope and should be refactored.

Consider when running release builds of your methods, and an Null reference exception happens on a 100 line method. No line number, just the method name. Figure that one out.

Frankly, I dont care how your internals look. Just please follow the public interface guidelines so I understand the semantics of calling the public functions: parameter names and function names that define what they do.

I just find it amusing (to the tune of Daily WTF) of just how little common sense devs apply to their code.

re: What does style look like, part 6

Larry Osterman — Tue, 16 Nov 2004 21:11:00 GMT

Eric,
That's pretty much what I do - members get an _ in front of the name to differentiate them.

I don't use visual studio for my editor (I use Epsilon), so I don't have the benefit of intellisense :(

re: What does style look like, part 6

Larry Osterman — Tue, 16 Nov 2004 21:21:00 GMT

CLR == Common Language Runtime - Also known as the .Net framework.

re: What does style look like, part 6

David A. Mellis — Tue, 16 Nov 2004 22:13:00 GMT

In all this talk about indenting, naming conventions, and comment standards, I think you've ignored the most important aspects of this code's style.

First, there's cleary some global state involved (otherwise, what's the call to initNodes() do?). Second, there seems to be some trickery with the default next node for new nodes. Otherwise, how does the linked list end up as a circle? Third, what does DeleteNextNode do? If it sets node->next to node->next->next, it's badly named, as "delete" is associated with memory deallocation, not removal from a list. Fourth, what's the Josephus problem? I'd prefer a brief description to the comments for each section of code.

I know that you're just using this piece of code as an example, but it's difficult to evaluate the effectiveness of these surface changes when more fundamental problems remain.

BTW, you have some typos in your final snippet. In the line:

while (newNode != Next(currentNode))

the "newNode" should be "currentNode". You're missing a semi-colon after the "int i" and you've forgotten to change the variable names in the comments.

re: What does style look like, part 6

Larry Osterman — Tue, 16 Nov 2004 22:25:00 GMT

David,
Your point is valid, there IS global state. This may be a poor example, as I said in the first post, it was chosen by opening a textbook at random and picking the nearest sample code fragment with significant amounts of code in it (I was lazy and didn't want to spend the time working on a good example :))

I'll fix the typos.

re: What does style look like, part 6

Alex — Wed, 17 Nov 2004 00:14:00 GMT

One thing to keep in mind is that C++ specifications reserve leading underscores for the implementation.

So calling a local variable _foo is a no-no in C++, and calling a local variable m_foo in C# is discouraged.

Interesting.

Myself, I like the camelCase and _local style when writing C++. I'm just not disciplined enough for true Hungarian sadly, so I've stopped trying to half-ass it with strFoo and iFoo.

re: What does style look like, part 6

Norman Diamond — Wed, 17 Nov 2004 00:42:00 GMT

> The first thing that's clear is that
> abbreviations are out,

So the typedef formerly known as I has to be INTEGER?

> and that variables should represent full
> English words.

Not Hungarian? Of course the language keywords are English, but why should variables be? Actually I think the C committee went too far when they allowed non-Italian characters in variable names, I think those should stay in comments and character strings, but it seems rather reasonable to have variable names using Italian characters to represent Hungarian or Japanese words.

Sometimes it seems kind of irrelevant, for example Gosa could be named ErrorRange instead of Gosa, but sometimes it's highly relevant. Consider an IME that recognizes ConversionKey and NonConversionKey and others in deciding how to convert among ItalianCharacters and JapanesePhoneticCharactersUsuallyUsedForPartsOfJapaneseWords and JapanesePhoneticCharactersUsuallyUsedForForeignWords and ChineseCharacters. It would be more readable to recognize the HenkanKey and MuHenkanKey and others in deciding how to convert among Romaji and Hiragana and Katakana and Kanji. (By the way, Microsoft's English language help files for the IME would also be more readable if they did the same. Some months after trying to guess what kind of key is a conversion key and what kind of key is a non conversion key, I finally figured out that Microsoft meant the keyboard's henkan key and muhenkan key.)

re: What does style look like, part 6

Larry Osterman — Wed, 17 Nov 2004 01:24:00 GMT

Norman, I'm describing the CLR conventions, which are pretty clearly anti-hungarian.

re: What does style look like, part 6

Guenter Tschech — Wed, 17 Nov 2004 12:53:00 GMT

For reading code from other people, I do prefer the CLR style, because it's much more "human" readable (versus "developer" readable in the hungarian notation).
But I see that in some cases you need to have prefixes to know what you have to expect from that variable.
But when programming with classes, you will sooner or later run out of prefixes that are short enough to be typed in (at least that's what I find), so the hungarian paradigm seems to fit more to the funcional world than to the OO-World (where the .net citizens _should_ live).
By using .net (and Visual Studio as your editor), you really don't need to put this into the name, because IntelliSense will pop up the type just when moving the mouse over the variable and just entering a period (hopefully in whidbey at any character) the list of members and locals will appear, so you get instant information about the type.

(maybe you missed that because you're hooked to Epsilon ?)

re: What does style look like, part 6

Larry Osterman — Wed, 17 Nov 2004 14:43:00 GMT

Guenter,
Even if I used visual studio, I wouldn't have the benefit of intellisense. The NT build environment (or the Exchange build environment) doesn't run from within visual studio, and the browser database that intellisense uses isn't generated.

And, like source level debugging, intellisense is a crutch, you shouldn't depend on it.

re: What does style look like, part 6

Guenter Tschech — Thu, 18 Nov 2004 14:15:00 GMT

Larry,

if you refer to VStudio 6.0, you're perfectly right, but although I am a programmer since Windows 2.11 (using the MS C compiler) and did not use intellisense at all in C and C++, I instantly switched to this behavior when turning into C# development, as it works much more reliable than the VS6 thing did...

Maybe this will get better inside MS when all code is ported to CLR, but I think this won't be too soon for Exchange and NT :-)