Browse by Tags

Tagged Content List
  • Blog Post: Seven Rules for Beginning Programmers

    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...
  • Blog Post: Wisdom in Lists–Really?

    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...
  • Blog Post: Revisiting the GoTo Statement

    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...
  • Blog Post: 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 followed by several revisions, starting over from...
  • Blog Post: 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 that language and how things are done in that language...
  • Blog Post: 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 is really the documentation for the project or the...
  • Blog Post: 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 only to be used by the person who wrote it, can get...
  • Blog Post: 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 up front to get the right results before getting...
  • Blog Post: 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 days that were not really so good I can't help...
  • Blog Post: 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 is self explanatory." Ah, yeah, right. Most will...
  • Blog Post: 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 to write the least understandable C program...
  • Blog Post: 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 to figure out any other program they come across...
  • Blog Post: 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 being used. In some languages they are and in some...
  • Blog Post: 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 at times. I have been a long fan of debuggers...
  • Blog Post: 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 its not always so much fun. Tricks often...
  • Blog Post: 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 of the standard language specification or an operating...
  • Blog Post: 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 of course very wasteful of time and processing...
  • Blog Post: 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 incorrectly or to do so in the wrong place...
  • Blog Post: Programming Proverbs 11: Use intermediate variables properly

    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 ...
  • Blog Post: Programming Proverbs 10: Use good mnemonic names

    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...
  • Blog Post: Programming Proverb 9: Get the syntax correct now, not later

    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...
  • Blog Post: Programming Proverbs 8: Avoid side effects

    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...
  • Blog Post: Programming Proverbs 7: Avoid unnecessary GOTO's

    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...
  • Blog Post: Programming Proverbs 6: Use procedures

    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...
  • Blog Post: Programming Proverbs 5: Construct the program in logical units

    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...
Page 1 of 2 (29 items) 12