Main Content

Learning to write high quality code in Lua

Archive - Originally posted on "The Horse's Mouth" - 2009-07-30 11:55:00 - Graham Ellis

What a wonderful opportunity this week - to train delegates in Lua programming (and Lua, byte for byte, is perhaps the best value language that I train in) but also to be in on the early stages of a project where it's not just a question of training on the language itself, but also in helping provoke thoughts with regards to the best way to make use of the language in the application. I was happy - no, let's say "delighted" to step into one of the siderooms at the end of the class and find the team leaders discussing programming standards and techniques, to the extent that they're planning a further course on the subject. Good for them - I'm sure that such a course will repay its cost many times over! They asked me if I was interested in presenting - yes, interested, but I don't have the materials, the knowledge in some of the areas, and they would do far better with a more local tutor who could come back in for a morning every couple of months to review progress with individuals.

I have, as is my normal practise, been writing code examples 'on the fly' during the course ... and on one of those I wrote today, I asked for a critical review from my delegates. In the culture, where everyone is so polite, I had to trigger the discussion - "I can see at least three things that I haven't done, which I should have done to make this into a high quality piece of code". And then they started to pick up my faults - (most of which were deliberate!)

• My code was uncommented throughout its body, meaning that it would be very hard to follow later, even by the original author.

• Variables within functions (at least I HAD structured my code into functions!) were not all declared as local - like Perl, Lua's variable are default global. And that means the a reuse of the function later could lead to some odd and hard-to-find bugs due to name conflicts

• The indentation of my code was erratic, again making it hard to read

• My functions, which would have been useful in other applications of the same data, were in the same file as my main program, meaning that without re-engineering my code could not be shared.

• Variable naming wasn't standard or consistent ... and we had already seen during the course how inconsistent variable naming slows down maintenance coding as the maintainer has to keep looking back to find out what variables were called, and what spellings and capitalisation were used.

• The output from my program was just a set of results - it didn't label the results in any way. So that means that a copy of the output given as a report to a manager would have needed extra work to document it to make it of any practical use

• There was no header block stating what the field was, which version, who maintained it, what it required. Once again, that makes it very hard to maintain.

• No user documentation ...


Our next Lua Programming course starts on 10th August 2009 in Melksham, UK. If you have missed that date, the course description page will give further dates - usually scheduled 9 to 18 months ahead. And if you're looking for a course for a group of delegates, we can arrange a private course at our centre or a on site course at your offices for you. And as you'll see from the blogs I am writing this week, that can be in the UK, or further afield ... look back and you'll read of courses in the USA, Saudi Arabia, Germany, Ireland, the Netherlands, Slovenia, Finland ... and this week Mexico.

I believe in teaching NOT ONLY the mechanisms of a programming language, BUT ALSO how that language should be well written - both in terms of the specifics for the language and in general computing terms!. If asked to teach "just the mechanisms of the language" on a private course, I would probably refuse, insisting on adding at least a few words to encourage good practise.