Browse by Tags

Paul Vick posted these Seven Rules for Beginning Programmers earlier this week and I have been thinking about them a lot. They make sense to me. As a professional developer you have to understand that these are the rules for beginners. The last item concludes with “ You may go beyond these rules after...

Like a lot of people I have an affection for lists that condense a lot of wisdom into a brief set of statements or items. Some time ago I wrote a series of posts on Programming Proverbs for example. That list (reproduced at the bottom of this post) came from a book that was every influential to me, especially...

In yesterday’s post I named the “GoTo” statement as basically a bad thing. To my surprise this started a short Twitter discussion and also came up in the comments. So I did a bit more research. I found this fairly balanced article called “Using gotos” by Steve McConnell . And Mark Guzdial twittered a...

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 followed by several revisions, starting over from...

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 that language and how things are done in that language...

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 is really the documentation for the project or the...

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 only to be used by the person who wrote it, can get...

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 up front to get the right results before getting...

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 days that were not really so good I can't help...

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 is self explanatory." Ah, yeah, right. Most will...

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 to write the least understandable C program...

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 to figure out any other program they come across...

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 being used. In some languages they are and in some...

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 at times. I have been a long fan of debuggers...

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 its not always so much fun. Tricks often...

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 of the standard language specification or an operating...

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 of course very wasteful of time and processing...

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 incorrectly or to do so in the wrong place...

Intermediate variables are variables that are used to break calculations down into several steps. For example the use of intermediate variables takes something like this: x = a + b * (sqrt(y) + w) and turns it into something like this: var1 = a + b var2 = sqrt(y) + w x = var1 * var2 ...

Mnemonic names are names that make it clear what they are for. I've always viewed mnemonic names as being an important part or self-documenting code. There is little question that they make reading someone's code a lot easier. But there is probably a better reason for using them even if you are working...

How often does students say they'll fix the syntax later? They are in such a rush to enter their code that they let "little" syntax errors slide until later. Or worst still they enter code carelessly assuming that the compiler with find and highlight the syntax errors for them. It's a tempting way to...

Side effects are actions that change things outside of a procedure, function or method. Generally this happens when a procedure modifies a global variable. I'm tempted to suggest that this proverb might just as well be "avoid unnecessary global variables." The problem here is that since the activity...

This was quite the controversy when it all started. Today some people go through a whole programming course without even learning that the language they are using even has a GOTO statement. An unconditionally GOTO statement barely exists in most programs today. It wasn't that way 40 years ago though...

The word "procedures" here is a bit of an anachronism I guess. Today we talk mostly of "methods " Perhaps we talk about "functions" or "subroutines" but we are really talking about the same things. We are talking about small routines with a defined way in and a defined way out. Generally we work pretty...

This is the fifth of a series of posts based on the book Programming Proverbs by Henry Ledgard . The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there . Comments on this "proverb" are of course very welcome here. To many Construct the...