Showing what programming errors look like - web site pitfall
Archive - Originally posted on "The Horse's Mouth" - 2013-03-06 08:44:10 - Graham EllisOne of the elememts of a programming training course is showing people what happens when something goes wrong. We all make "silly" coding mistakes from time to time, and these often result in a syntax error when we compile (C, C++, Java), start to run (Perl, PHP, Python, Ruby, Lua) or reach the statement with the error (Tcl). Such errors are "hard" in that the code fails, very obviously, to execute and we can't proceed with testing. But sometimes our silly coding mistakes result in source code that's syntactically correct, but does the wrong thing when run. Sometimes that's dramatically wrong - at other times, it's subtle. And showing newcomers to a programming language (perhaps newcomers to programming) the more commonly nade mistakes of this sort, how they manifest themselves, and how to be sure that you spot them all as soon as possible and certainly before you release code to users is an important element of what we do.
So - our training notes have a few examples in them which intentionally show the errors, and their effect. They're followed by an explanation of the problem, and a corrective action.
All source code examples from our notes are available on this web site; we offer a listing my module [here] and a global index [here] to help past delegates, and others find them. And every single example carries the explanatory text:
| This is a sample program, class demonstration or answer from a training course. It's main purpose is to provide an after-course service to customers who have attended our public private or on site courses, but the examples are made generally available under conditions described below. Past attendees on our training courses are welcome to use individual examples in the course of their programming, but must check the examples they use to ensure that they are suitable for their job. Remember that some of our examples show you how not to do things - check in your notes. Well House Consultants take no responsibility for the suitability of these example programs to customer's needs. |
Frustratingly, that message doesn't always get read - the examples may be seen out of context. From an email last night:
you have ($age = 21) which is an assignment statement, and as such always evaluates to true
it should be ($age == 21) or even ($age eq "21")
It might also be nice to add 21 to your test set so that people see that the elsif works as opposed to two different tests over 21 And those words mirror fairly well what the notes for the old "Introduction to Progamming in Perl" course used to say ...
| If you use a single = sign, you're asking for the expression on the right to be evaluated and saved into the variable named on the left, and then the resultant value to be tested to see if it's true or not. That's very rarely what you mean in an if statement, and never what you mean if you're assigning a constant values. You should probably have write a double equals == which compares the numeric value of the expressions to the left and right of the == comparison and gives a true result if they're the same, and a fales result if they differ. There are other types of comparison available too, which we'll look at later ... |
Our courses will ALWAYS show you what can go wrong with code - it's a necessary element of testing to make sure that delegates who leave us are ALWAYS aware of the risk of program bugs, of how they manifest themselves, of what causes them, and how to fix them, and I can't think of any better way to illustrate the point than by a demonstration of code which contains actual errors, and running it to show error messages and / or incorrect output. And we're committed to making our code available post-course to all delegates. Which leaves me with a bit of a problem - examples read out of context, and flagged as wrong and indeed very silly to have included on the web site of a company that knows what it's doing!.
I've revisited the example that shows the error, changed the title to indicate that it shows the wrong way to do it, and added extra comments in the code to that effect as well. I've done that reluctantly, as the source code example is no longer what's shown in the books, but if 1 person reported the page as having a mistake, 10 others will probably have thought so and not bothered to report it, and the view of us they've formed will have done us no good. Let's hope that people actually read the extra stuff I've added!
See for yourself ... the updated example is [here], and there's also a corrected example [here].
The suggestion of adding an extra data test case - 21 - is an excellent one, and I've done that. Thanks to my correspondent Adam for the suggestion (and indeed for his email which triggered the extra text within my example to help explain what it shows rather more thoroughly!)
P.S. - Some similar examples
Here's another example in the same course module that may also look wrong out of context. We're demonstrating the protection of \ and $ characters within double quoted strings in Perl ... there's a better (corrected?) example [here].
The VAT rate has changed from 17.5 to 15 to 17.5 to 20% ... and there are examples in past notes showing each of these rates. We have NOT gone back to exit the web site, so you'll see examples such as [here] and [here] using an old rate. For a live application, you should isolate changeable values such as the VAT rate into a configuration file, but to do so in an early course example would obfurscate the code for the newcomer ...