but this is the irony of the situation..!!

"To Follow" or "not to Follow", its like --"to be or not to be" ..

the dichotomy of thought is certainly appreacited :)_

"Design classes parallel to their physical counterparts"

This one goes against what Bjarne says in "The C++ Programming Language." A class should reflect a concept. A physical counterpart is probably a class of concepts.

He would have done better to just link to the Wikipedia article on Ignore All Rules [1]. It gets the point across – rules and guidelines are important to follow, but in the end they may not cover your situation.

[1] http://en.wikipedia.org/wiki/Wikipedia:Ignore_all_rules

Oops, to be more clear, he says the quote is a bad idea, but it's a good idea.

I can't believe this is actually happening. I read most of the article, and a huge section of the digg comments. Did anyone else actually realize that the list is a bunch of programming advice NOT to follow? He doesn't agree with them himself! THE LIST IS WHAT YOU SHOULDN'T DO! Tons of Digg comments bash the author because of what he wrote, when he SPECIFICALLY introduces the list with: "The top ten list of programming advice to not follow:"

http://www.cjmillisock.com

I see now that SOME people understand that the list was advice not to follow, and felt that the advice was actually good advice to follow.

But how many people read the list of advice not to follow and thought, "I already heard that suggestion and I already do all these things." Following off of others' opinions/digg comments, they trashed this author for writing some material that is actually thought-provoking for some.

Like the fourth digg comment: "I feel like I'm back in preschool when I read this. Any good programmer already knows all of these things."

And the fifth: "No digg for really crappy advice." It's not advice, it's advice to disregard.

Twenty or so down: "I do agree on the part about putting the author name, date, changed etc in the comments above a method." Isn't Kristian saying that this advice is commonly encouraged, but should be avoided?

Am I reading this incorrectly?

CJ, this points at another piece of programming advice – always use positive names for booleans ;)

userUnregistered = true; // can be confusing
userRegistered = false; // can be easier

I love (not) how the Internet Explorer advanced options dialog is sometimes using negation in its check boxes. I'm paraphrasing, but it's along these lines:

[x] Don't play sound on web pages
[ ] Show animations

etc. :)

This is why user expereince /interface experts are becoming more and more important in the s/w process.. what lurks underneath the code --does not matter to the user.. as philipp demo's above, the IE are cross negating thier features and verbiage..

   I normally use these (3) fundamental rules for any processs..btw which also works for in the s/w dev process too!!

1) A rule must be relevant to a process. If the rule does not affect the process in a materials way, remove it.
2) A rule must be unambiguous. If 10 people are given a situation and a rule, and they do not give the same answer, then the rule is ambiguous.
3) A rule must be clearly stated. If someone cannot read the rule and explain it back, then it is not clearly stated.

You guys should write a top ten list of programming advice TO follow. I don't know about others who are in the beginning stages of their programming careers, but I'm always interested in finding best practice ideas.

CJ,

I've created a list at http://www.timalmond.com/journal/2006/2/14/top-10-list-of-programming-advice-to-follow.html if you are interested.

Thanks for the post Tim. Very good read!