Tim Almond

Following on from a challenge from CJ Millisock, after the quite ludicrous post in the Top 10 of Programming Advice to Not follow, here’s my top 10:-

10. Abstract rules to the data. Instead of building something into your code that makes an exception for customer John Smith, consider what it is about John Smith that creates that exception. For instance, if John Smith is good pals with the CEO, then have a "CEO good pals" indicator on the customer, and check for that.

9. Let the machine handle catastrophic error checking. This isn’t error checking like the user putting a date in the past in. This is more like connection from application to database is broken. The reason that I prefer to leave it to keel over is simple. Handling it yourself means cascading the error up, with a reasonable chance of it being missed. I’ve seen applications which had to write something to a database not do so, and the users had no idea that all their work wasn’t being saved, because the default behaviour was overriden, a response returned, which was then not checked. It’s also my experience that one area that is most likely to not get tested.

8. Don’t be clever. Never complicate your code beyond where you have to, and consider the poor guy who’s going to have to pick it up. That 7 level nested if statement may be a work of art, but it’s often easier to find a point where it can be logically separated into a function. Also, having a function that says:-

string fmtdplate=fmtlicenseplate(customer(file(fileid).searchcustomer(customername).customerid).licenseplate)

might be compact, but how’s someone going to debug that? Sometimes, breaking up a complex line of code into smaller steps makes things easier to follow, and will generally have an insignificant effect on performance.

7. Consider your testing. When writing a program, consider how you are going to debug and test it before you build it. Separating the UI from the logic is a good move, as you can then build a "wrapper" which simly calls the logic and bypasses the UI. The UI still needs testing, but you’ve cut down your testing iterations.

6. Don’t comment out code, delete it. Get a source control system instead. Commenting out code only leads to confusion. Worst of all, is code mixed into commented and uncommented. Yuk.

5. Optimise where you have to. Anything else just adds complication which creates cost. If the job runs overnight and takes 6 hours, then sleep soundly, you’ve done your job. If it takes 20, you’d better look at getting it running a bit quicker.

4.  Keep documentation concise and relevant. A program specification that is written from the code, and tells people what the program does in such terms is useless. The code does the same job. A function called "determineprimefactors" doesn’t need a comment that says "this function determines prime factors", nor do comments that say "In this function, we send out an email" when the next 2 lines will tell almost anyone that that is exactly what you are doing. A specification should tell someone what the program should do, and should be more about the goals, and rules, not implementation. Comments are best used as insight into complex code. Now sure, someone can follow it through, but if you give some idea of the mechanics in overview, it can accelerate the developers understanding.

3. Don’t be afraid of rewriting. Most companies are afraid to touch their data models, and as a result have to build incredibly complicated, and often bug-ridden changes to shoehorn data into their data model.

2. Reuse, reuse, reuse. This stuff can cost a lot of time and money. The more you can wrap thing into components, the cheaper it will be. Building things with OO from the start can appear more expensive, but the overhead will quickly pay for itself if reused even once.

1. Don’t program! Need a graph control for your .net program?  Why are you writing it, and not downloading it from a company that can sell it to you for less than a man day of your time. A company that’s got coders and testers working fulltime on it. A company with thousands of customers making suggestions, finding bugs and so forth.

 

Tags: Software Development //