Archive - Originally posted on "The Horse's Mouth" - 2007-01-21 06:42:04 - Graham Ellis
Don't ask what class an object belongs to Don't enquire where your cursor is Don't do two things in a call Don't duplicate data or code Don't put two or more values in the same cell
There's lots of different ways of coding - from "dog's dinner" to "Picasso". The dog's dinner looks a mess and is very quickly gone and forgotten (even by the dog, who wants more), but a Picasso is a piece of beauty and lasts for generations. We can all feed the dog, but very few of us are Picassos. What we can all do is to make a good job of decorating a room so that it lasts and looks fresh for a year or two, and functions well without redecoration for pehaps 5 or 10 years.
The first time you slapped paint on, as a child, it wasn't going to last for even a year, was it? But with practise and applying a bit of discipline to yourself, you can do rather better now? Thought so! And it's very much the same with coding; your first program on a Perl course or your first MySQL database will be written to test basic functionallity - to check that you CAN store that data / stick that paint roughly where you want it on the wall. Improvements come once you understand the mechanism and have tested it.
Here are some of the improvements that you can make between "first test" and real application:
Don't ask what class an object belongs to. Use polymorphism, so that no matter what type of object you run a method on, your code will automatically do the right thing. If you redefine what an operator or method does (oveloading) by defining two blocks of code with the same name and footprint, then your need for lots of switches or if, elif, elif, elif sequences is eliminated.
Don't enquire where your cursor is, or what status your application is in - remember it in your code. Any piece of code that goes out to discover where it stands / what step it's at gets complex and hard to maintain - and such enquiries are prone to error. Much better to remember - it's often as simple as having a single integer status variable.
Don't do two things in a call. You want to format a piece of data and print it out? Sure - write a piece of code to do it and it'll work well. Until, one day, you want to format the data and do something else with it. Put it up on a widget or burn it into a graphic, perhaps. And the piece of code that's called from all over your program to do "a" and "b" suddenly doesn't seem so clever as this time you only wasnt "a". Much better to write code that performs a single logical operation in a single call; you can always write a wrapper to bring two commonly used operations together if you need to do that frequently.
Don't duplicate data or code. If you find yourself cutting and pasting code - WRONG. You're creating a branch which will give you two threads to debug, maintain for the life of the code. Better to take the code that's going to be used several times over, give it a name (i.e. make it a function, sub, def, proc) and call it by name. "But I need to change some things in the copy" you say. Yes indeed - those things you need to change are helping you to identify which elements are your parameters.
Don't put two or more values in the same cell. As soon as you start putting comma separated list, multiple space separated names or whatever in a string or database cell, you have an issue with the commands or code that searches them. One value per simple variable, one value per cell please. In programming terms, you can use lists, tuples, dictionaries (Python), arrays and lists (Tcl), hashes and lists (Perl) and arrays or any one of the many utility classes (Java). In database terms, you're looking at an additional table and a join. The decign may get more complex, but the data is kept simpler and unique. Find a data error and you've just one correction, not a multitude!
Why not review your coding against the suggestions I've made above? Get into the habit of following the guidelines suggested. And you'll find that you naturally move from producing a very temporary solution to an issue to something that will, far better, stand the test of time.