2000 Preliminary Round: Commentary

The standard of entries in this year's preliminary round was higher than in previous years. Most teams got at least one task working, and the average mark was 34/100 (which corresponds roughly to two working tasks and one or two partially working tasks). This shows a pleasing level of programming skill.

Performance marks were awarded for correct behaviour according to the specification. This year, as in all previous years, many teams lost easy marks as a result of not reading the questions carefully. For example some teams lost a mark on task 2 (factor pairs) because they forgot to follow the instruction to "print the smaller of the numbers in the factor pair first, then the larger one".

This was the first year we have taken style into account in the marking. On the whole programming style was quite good. Teams looking to improve their style should consider doing the following:

• Wherever possible, split the task into smaller problems and write helper functions/procedures to do this. As an example, the most common method for solving task 1 (anagrams) involved converting the two strings to lowercase. In a situation such as this it is better style to write one function that does the job of converting a string to lowercase, and then call this twice in the main program rather than repeating the conversion code in the body of the main program. Using separate functions also helps greatly in debugging and designing your programs, which should be helpful in the competition.
• Choose variable and function names that reflect what is being done. Some teams wrote programs consisting entirely of one or two letter variable names. These are very hard to understand and thus are poor style. Using a single letter variable for the index of a loop is fine, but when there are several scattered throughout the program it is hard to tell what i, j, k and x are all storing.
• Due to the limited time, we do not expect to see detailed comments in the code, but in places where the program is not obvious (e.g. some multiply nested loops) a short comment stating what is being done would be very helpful.
• Try and set out your code so it is easily readable. You should indent the bodies of if statements, loops and other functions so that the code stands out from the rest.

It was good to see teams using a variety of languages to solve the problems. Basic and Visual Basic were again the most popular languages (used by over half the teams) followed by C/C++, Pascal/Delphi and a few others. As for last year teams using Basic tended to do less well than teams using other languages.