Hurray, thanks for all of the responses!
3. Well, the problem with it is that it can "change" code when you don't mean to.
This problem is eliminated if everybody's editor does it, but you're right about MSVC++.
That's not a big one for me.
6. I guess this goes hand in hand with something else important I left out, and that's never exclude braces from a branch, even when the block will only contain one instruction. The reason for this is that it prevents a very common mistake:
Programmer #1 writes some code:
while (fred) {
if (jack == jill)
jack += 1;
}
Then, Programmer #2 edits the code, but fails to notice the lack of braces or mistakes the closing brace of the while loop for the closing brace of the if:
while (fred) {
if (jack == jill)
printf("jack=%d\n", jack);
jack += 1;
}
Suddenly, the meaning of the code changes dramatically. So when braces are always used for all branches, you will never see an else in the code unless it looks like one of these two:
if (jill) {
jill += 1;
} else if (jack) {
jack -= 1;
} else {
jill = jack = 0;
}
Thus, it becomes both consistent and symmetrical. For me, I see the entire sequence of characters
} else { as one operator because I always use them together. However, improper or inconsistent indentation will blow its readability right out of the water because it depends upon indentation to visually demarcate code blocks. I don't want to be rigid or demanding, but I also have a lot invested in this project, (even if I was absent for a while). What is perhaps most important is that the formatting is consistent and that if we're going to make a change from a pre-existing format that there is consensus on it so we don't have multiple people pulling in different directions. I've worked on a lot of other people's code over the last 15 years and the most frustrating is when it's inconsistent.
7. I'm sorry, I've been trying it out and it drives me nuts, lol!!
I don't think the if's bother me as much as the function calls, but again, I tend to depend upon the code editor highlighting the opposing parenthesis. I'm not used to adding a space between the if and the open-paren, but I find this very helpful and I'm trying to get in the habit of doing it (and I have my code formatter setup to do it). :'(
8. Ahh, good summary Silnarm!
17. Yea, the colen and comma at the start of the line is something I just picked up earlier this year and really liked!
Regarding Mr. Singleton, it looks a bit cleaner, but I have to soak it in. I agree with hailstone about avoiding the overuse of the Singleton pattern, but all of these singletons are already in existence. The only place I have to disagree is for parts of the code dealing with changes in the program state where theWorld, theMap, theGame, etc may not be valid (because they only come into existence when a game is created), or in areas of the code that may be active when these are not alive. Other than that, it seems sane and may be a really good idea. But I have to soak it in.
In fact, it may be worthy of it's own topic.
Also, keep in mind that Singletons tend to make a program's structure very rigid and makes it harder to implement unit tests that execute your code in a different environment, and often restricts the order of object creation beyond what is necessary.
Then there are two more that I think you guys know already and that's:
18. Prefer object references to pointers. The general exclusion to this is when an objects may or may not exists (i.e., be NULL) and then you have to have a pointer.
19. Prefer passing const reference to passing objects. I think that one is a general no-brainer, but it's worth having in the standards, IMO. I also prefer to pass 64-bit values (double and long long/int64) as const reference because (I believe) it generates less instructions on a 32 bit machine and results in the same number of instructions on a 64 bit machine (but maybe I'm wrong
).
