Browse by Tags
All Tags »
programming proverbs (RSS)
digg_url = "http://blogs.msdn.com/alfredth/archive/2009/05/21/revisiting-the-goto-statement.aspx";digg_title = "Revisiting the GoTo Statement";digg_bgcolor = "#EEEEEE";digg_skin = "normal"; digg_url = undefined;digg_title = undefined;digg_bgcolor = undefined;digg_skin
Read More...
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
Read More...
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
Read More...
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
Read More...
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
Read More...
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
Read More...
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
Read More...
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
Read More...
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
Read More...
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
Read More...
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
Read More...
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
Read More...
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
Read More...
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
Read More...
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
Read More...
