2011-08-01 Correcting exams (Basic Java programming) at university gave me some insights. I went through about 70 versions of the same two functions. This had been a great experience. Here's what I discovered: 1) If the code is well formated/layouted, it is often also correct. If code is badly formated, it is likely wrong. I tell you: Do format your code well! There are lots of ways to format code. I used to say: ``Important is consistency.'' But now I rather say: ``There is a good reason to use one of the common styles.'' Most times, the best choice is formating code the same way as the language designers do it. Your code will contain less errors. Believe it or not. 2) So many errors are off-by-one errors. This of course isn't news. It just im-/depressed me how many times they were made. (One was a is_sorted() function.) Compilers can't really help you with the task of detecting these errors. The two successful encounters are: Use idioms and test simple cases. Students who used uncommon for-loops (e.g. decreasing) almost always made off-by-one errors. Those who used the for-loop-idiom produced much better results. 3) Bad identifiers make everything more complicated. Okay, this had been an exam where students have few time but take this: int h = a[i]; int g = a[i+1]; if (h > g) ... You need to read it again and again and twist your mind like if there are multiple negations in a boolean expression. Everyone expects `h' to be after `g', hence never put other meaning into it. Another example: If the function is called `sort' but actu- ally implements `is_sorted', problems will start to rise. Better name it without meaning (e.g. `foo' or `CubaLibre', as I have seen *g* ) than with wrong meaning. Well chosen identifiers, however, are the best improvement to code readability. Teaching programming should much more be: Teaching style and structure. Everything else will follow automatically then. http://marmaro.de/lue/ markus schnalke