Not all programming advices need to follow, measure them by yourself
There are lots and lots of programming advice on the web. Some of it good, some of it less so.
Kristian D. Knudsen's article Top Ten of Programming Advice NOT to follow showed some extraordinary standpoint for programming principles/standards. And here I wanna share something beside my experiences and thoughts on some of them.
1. "Design first, then code"
Yes, designing first and then coding simply doesn't work.
I think every programmer has experienced a project with no planning turning into a mess. It is at that time that you realize that the only decent way to code is by designing things right from the start. Only now the frustration is even greater when you realize that your beautiful design isn't prepared for exactly this new feature that you are to implement now.
And on the other hand, you find it is almost impossible to sketch an entire design document with UML diagrams and everything without making mistakes. At least, you cannot do so any faster than you could have simply written the code.
So you're in a dilemma, aren't you? What to do then?
In my opinion, you SHOULD think before you code, but think for hours, NOT days. And reflectoring continually to improve your comprehension of the project and your design. Experiences is important, so don't be afraid to make mistakes, go ahead, guy!
9. "Use unsigned integers for values that can only be positive"
Unsigned integer types seem nice at first because they feel safer. They have a constraint that says "this variable will never become negative" which makes perfect sense for a number of variables, such as sizes.
Problem is, this constraint is enforced by wrapping rather than bounds checking (at least in C and C++ - in C# you can turn on overflow checking and as far as I know, Java doesn't have unsigned integer types). Hence, it will be hard to find out the overflow errors. I've got such problems some times and afflicted with this so much.
------
And other advices which you should not follow may be as follows:
2. "Code all the corner cases immediately, cause otherwise you'll never go back and fix things"
3. "Be tolerant with input and strict with output"
4. "Use the singleton pattern for variables that you KNOW you should have only one instance of"
5. "Use accessors or properties rather than public fields"
Why getter and setter methods are evil.
6. "Write lots of comments"
Well-written codes are the best comments.
7. "Make sure your team shares a common coding standard"
8. "Design classes parallel to their physical counterparts"
10. "Use error codes instead of exceptions"
11. Do NOT believe all my words
Just read it and think them over by yourself 
Tags: 编程