Welcome to MSDN Blogs Sign in | Join | Help

Browse by Tags

All Tags » programming proverbs   (RSS)

Programming Proverbs 26: Don't be afraid to start over

The statement "Don't be afraid to start over" seems obvious to the breed of programmer today who starts off assuming that they will always throw away the first several versions of their program. There is some indication that this idea of rapid prototypes

Programming Proverbs 25 Consider another language

What's that old line about if all you have is a hammer all your problems look like nails? There are some programmers who only have one programming language in their tool box. They way they look at programming problems is colored by what can be done in

Programming Proverbs 24: Re-read the manual

I've been telling students and others that " reading the manual is the shortcut " for years. I really believe it. When a program isn't working out the way one expects re-visiting the manual is often a great short cut. Sometimes the manual in question

Programming Proverbs 23: When the program is correct, produce good output

This proverb is a corollary to the last post in this series . While getting the program correct and the right results is the first priority that doesn't mean that the results can be tossed out in any old way. A programmer's program, a program written

Programming Proverbs 22: Get the program correct before trying to provide good output

In some ways I think this is one of those proverbs that was more important back in the days when batch jobs were the way things worked. On the other hand there is an important, if perhaps more general, bit of advice here. That advice is to spend the time

Programming Proverbs 21: Hand-check the program before running it

Hand checking code seems to be a dying art. At least for students that is. Throw some code into the IDE and hit F5 to compile and run and then see what happens. "Ready, Fire, Aim" At the risk of sounding like the old guy reminiscing about the good old

Programming Proverbs 20: Provide good documentation

Well what in the world is good documentation? Now there is a question for the ages. Lots of programmers hate to document their work. I've heard more than a few programmers over the years say things like "you want documentation? Read the code. The code

Programming Proverbs 19: Prettyprint

While compilers generally don't care about how code looks as long as it follows the rules on syntax. Those rules generally are there for the convenience of the compiler and not for to make the code easy to read by humans. In fact there is an annual contest

Programming Proverbs 18: Use Comments

Is there anything so obvious to an experienced programmer that is so hard to get across to students than comments? Students know that they are so smart that they will remember everything about their programs. And of course they think they are smart enough

Programming Proverbs 17: Never assume the computer assumes anything

The computer doesn't know what you mean, it only knows what you tell it. How often do we tell people that? Pretty often if I am any indication. And yet people do assume all the time. They assume that variables will be cleared out by the system before

Programming Proverbs 16: Build in debugging techniques

When ever programming teachers get together one of the debates that often starts up is between using a built-in debugger or using other debugging tools - most commonly extra print/display statements. It is an interesting debate and can get quite religious

Programming Proverbs 15: Avoid tricks

Tricks are fun. It is often pretty satisfying to add a bit of code that is tricky, difficult or perhaps something that not everyone is going to understand. Well it's fun when it is done but later when the code has to be changed, modified, or worse - debugged

Programming Proverbs 14: Avoid implementation-dependent features

Implementation-dependent features are features or the the hardware or operating system or other part of the platform that is not available on other platforms. For example a specific piece of floating-point hardware or a language feature that is not part

Programming Proverbs 13: Do not recompute constants within a loop

This was big in it's time because compilers were pretty dumb back then. If you added one to three inside a loop that ran a thousand times then the computer would add one to three a thousand times. Hopefully it would come up with four each time. This was

Programming Proverbs 12: Leave loop variables alone

Another way of expressing this is to use loop as if they were read-only constants. Loop variables should be initialized and changed only in the loop statement itself. The problem with doing it anywhere else is that it is too easy to either make the modification
More Posts Next page »
 
Page view tracker