Additional profile information on Alfred Thompson at Google+
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 write code but it is seriously flawed.
The big problem is that sometimes one syntax error can be masked by another. The problem may show up later as a hard to debug "logic" error. This is not a good situation to be in. Code with lots of syntax errors can make things bad enough that several passes through a compiler will be required to get things to compile. That pretty much guarantees that logic errors have been there somewhere.
A lot of IDEs do syntax checking on the fly as code is entered. I think this is a great thing as it tends makes many errors obvious right away. These features are not perfect though so the programmer is still obligated to pay attention to what they are doing. The ideal should be to have no syntax errors in the first compile. One isn't going to hit that all the time because of typographical errors but it should at least be the goal.
This is the ninth 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.
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 is not clearly in the functions description or prototype it is far too easy to forget (or not know in the first place) that it is taking place. This makes debugging the problems that it inevitably causes quite difficult.
These days good programmers tend to avoid global variables. Global constants which cannot be changed are very valuable and safe. But you really want to avoid directly changing anything outside the scope of the local method.
This is the eighth 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.
I arrived in Covington KY where SIGCSE has returned this year. SIGCSE was here several years ago and some of the employees in the hotel and conference center are wearing buttons that says "Welcome Back SIGCSE." I think that is a nice touch. It is a small thing but a big thing all at the same time. I think as computer science people we run into a lot of things that are both small and big at the same time. Just think of the problems a missing or extra semi-colon can cause in a program.
I'll be here for the whole conference. If you are also at SIGCSE look me up. I should be hanging around the Microsoft booth a lot. But I'll be visiting other booths (hello College Board booth) and some of the sessions in the program. If you are a high school CS teacher who is going to be here on Friday and interested in lunch you really should find me. Hint hint. Tease Tease.
A lot of regular attendees are here. I've seen some people from the College Board and the AP CS development committee (previously anyway). Chris Stephenson from the CSTA is here and we talked briefly already. The people who show up for SIGCSE are wonderful and they are the reason this is my favorite conference of the year.