Thursday, June 23, 2005

Horrid

I really, really, really hate all of the following:
  • for(;;)
  • if (null != variable)
  • const int CONSTANT_NAME = 5
It's not for(;;), it's while(true). It's sad that you even need the (true) on there in C. Next, write your if conditions like you would speak them; you don't ask someone, "hey, is empty that box?" Finally, your keyboard has a shift key. Learn how it works.

15 comments:

Andy Rutledge said...

In semi-defense of "if (null != variable)", I was taught to do it that way because C allows assignment in a test expression (which is stupid).

The syntax is, of course, used to avoid the accidental assignment of variables if you accidentally used a "=" instead of a "==". If the constant is on the left, it would give you a compiler error, which was better than accidental assignment.

But I agree, it's annoying, and now that I code nearly exclusively in Java I can safely mistype "if (variable = null)" and get a compiler error to point it out for me.

Travis said...

Right. But, I mean, my lanugage of choice uses "=" as its comparison operator, and even I don't mistype things like "if (i = 5)" in C/C++/C#.

I'm glad you think that assignment in a test expression is stupid. Like anything, it has its uses, but I don't think that those uses warrant the danger or the readability tax. I think that VB has the near-perfect solution to the problem; = is an assignment operator if the only thing before it in the statement is an l-value, and a comparison operator anywhere else. The only thing that I think should be improved is that x = y = 0 should throw a compile error instead of setting x to the answer to the question "is y equal to 0?" This is worse in VB than elsewhere because casting y = 0 (boolean) to x (integer, presumably) is valid and implicit.

stack said...

...why are we crying about the const one?

Matthew Beermann said...

I've probably just been using Java for too long, but I see nothing wrong with your third example - that would be Sun's official style...

stolee said...

i prefer the following capitalization for variable names

ALL_CAPS_AND_UNDERSCORES : constants and static variables
camelHumpSyntax : instance members
lower_case_and_underscores : local variables

this keeps the scope of all variables pretty clear.

Travis said...

The correct way to case variables is TitleCase everywhere. You are allowed one underscore at the beginning of class variables if they would conflict with properties of the same name, though only until a language comes up with a better way of differentiating them. Under no circumstances may you use all caps or have underscores in the name of something. You may use only lowercase letters if the variable name is simply "i" or "dx" or something similar. Case sensitivity in identifiers is right out.

If you need to look at the case of something to figure out where it lives, you've probably got deeper design issues. And, in that case, you can still hover over the identifier. Any editor that doesn't tell you what an identifier is when you hover over it probably isn't worth using.

Matthew Beermann said...

Correct way? It's a good thing I know when I'm being baited. ;) I'll follow the recommendations of my language, and you yours. http://www.sun.com/software/sundev/whitepapers/java-style.pdf

Travis said...

Properly forming variable names in the manner I described is not the officially recommended VB or C# style, though it's quite close to the recommended VB style. It's just the way that things should be done.

When I'm President, I'll make sure that my coding standard will become law. I'll call it the "Anti-Variable Terrorism" bill and it'll get passed without so much as a cursory examination. But, don't worry, I'll make sure that Congress tacks on a rider that restores at least some of the basic civil rights you've lost over the past few years.

stolee said...

coding standards are present for one thing: code readability. if i can read a variable and instantly know it's scope without having to look anywhere else, i call that readability.

also, classes should be in TitleCase, so you know when you are calling a method on an instance or a class. again, quick readability.

Travis said...

Well, really, coding standards are there for two things: (1) consistency, and (2) so that the person who wrote the coding standard thinks it's more readable. Clearly the same code is not equally readable to everyone, or there wouldn't be any contention. This consistency is quite important for stupidly case-sensitive languages like C++, because there's nothing worse than having one string class that uses ->length() and one that uses ->Length(), and getting a compile error because you used the wrong one.

Editors now are smart enough to be able to color or otherwise annotate my code so that the actual variable name doesn't need to tell me that information. Also, if I can't tell what a variable is from its name, I should fix that instead of taking the lazy way out and doing Hungarian. Perhaps you think that it's fine to have a variable named m_pvmdDict, but I find that infinitely less readable and scannable than Dict or _Dict. I'd even allow _pDict in C++ because of C++'s stupid insistence on having both an . and a > operator when only one is necessary. Same with CSIDL_LOCAL_APPDATA; I would have found [Folder]LocalAppData easier to read. If I couldn't figure out that was a constant by its name, then there are probably other issues with my code.

It all comes down to what you want your code to be. I want my code to be a clear, consise, explorable transcription of my thoughts and what I want the program to do. If you want your code to be a compact, terse, information-dense script of how you want the program to work, then you're going to have a very different coding style from me.

Travis said...

Typo: "stupid insistence on having both an . and a > operator" should have been "stupid insistence on having both an . and a -> operator".

At least can we agree that using spaces instead of tabs is roughly equivalent to genocide?

clay said...

Until the world decides on a standard size for tabs in editors (which will of course be the equivalent of 4 spaces), the replacement of tabs with spaces is morally obligatory.

Josh said...

"Tabs are stupid" generalizes to "ASCII is stupid", both of which are true statements.

Luke said...

I don't understand why the fact that the visual representation of a tab isn't standard would influence you to not use tabs; in fact, that's more flexible. You, as the developer, can determine what you like the tabs to look like.

I hate working in a file that has spaces for indents. I immediately figure out what number of spaces they use and run a replace on it.

:%s/ /\t/g

Travis said...

The excuses I hear about that are "the other code is that way" (which is not really okay; just fix the existing code) and the fact that Notepad, WinDiff, and the command prompt are hard-coded to eight-space tabs for DOS backward compatibility. But, yeah, lame reasons, and certainly nothing to justify using spaces instead of tabs.