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.
(written 2007-01-21 06:42:04)

 H115 - Designing PHP-Based Solutions: Best Practice
  [2430] Not just a PHP program - a good web application - (2009-09-29)
  [2221] Adding a newsfeed for your users to a multipage PHP application - (2009-06-06)
  [2199] Improving the structure of your early PHP programs - (2009-05-25)
  [1794] Refactoring - a PHP demo becomes a production page - (2008-09-12)
  [1694] Defensive coding techniques in PHP? - (2008-07-02)
  [1623] PHP Techniques - a workshop - (2008-04-26)
  [1533] Short and sweet and sticky - PHP form input - (2008-02-06)
  [1490] Software to record day to day events and keep an action list - (2007-12-31)
  [1487] Efficient PHP applications - framework and example - (2007-12-28)
  [1482] A story about benchmarking PHP - (2007-12-23)
  [1391] Ordnance Survey Grid Reference to Latitude / Longitude - (2007-10-14)
  [1390] Converting from postal address to latitude / longitude - (2007-10-13)
  [1389] Controlling and labelling Google maps via PHP - (2007-10-13)
  [1381] Using a MySQL database to control mod_rewrite via PHP - (2007-10-06)
  [1323] Easy handling of errors in PHP - (2007-08-27)
  [1321] Resetting session based tests in PHP - (2007-08-26)
  [1194] Drawing hands on a clock face - PHP - (2007-05-19)
  [1182] Painting a masterpiece in PHP - (2007-05-10)
  [1181] Good Programming practise - where to initialise variables - (2007-05-09)
  [1166] Back button - ensuring order are not submitted twice (PHP) - (2007-04-28)
  [1052] Learning to write secure, maintainable PHP - (2007-01-25)
  [945] Code quality counts - (2006-11-26)
  [936] Global, Superglobal, Session variables - scope and persistance in PHP - (2006-11-21)
  [896] PHP - good coding practise and sticky radio buttons - (2006-10-17)
  [839] Reporting on the 10 largest files or 10 top scores - (2006-08-20)
  [572] Giving the researcher power over database analysis - (2006-01-22)
  [563] Merging pictures using PHP and GD - (2006-01-13)
  [426] Robust checking of data entered by users - (2005-08-27)
  [394] A year on - should we offer certified PHP courses - (2005-07-28)
  [340] Code and code maintainance efficiency - (2005-06-08)
  [261] Putting a form online - (2005-03-29)
  [237] Crossfertilisation, PHP to Python - (2005-03-06)
  [123] Short underground journeys and a PHP book - (2004-11-19)

P711 - An Introduction to Standards in Perl
  [2375] Designing your data structures for a robust Perl application - (2009-08-25)
  [1863] About dieing and exiting in Perl - (2008-11-01)
  [1853] Well structured coding in Perl - (2008-10-24)
  [1728] A short Perl example - (2008-07-30)
  [1555] Advanced Python, Perl, PHP and Tcl training courses / classes - (2008-02-25)
  [1395] Dont just convert to Perl - re-engineer! - (2007-10-18)
  [1345] Perl and Shell coding standards / costs of an IT project - (2007-09-11)
  [1221] Bathtubs and pecking birds - (2007-06-07)
  [965] KISS - one action per statement please - Perl - (2006-12-05)
  [743] How to debug a Perl program - (2006-06-04)
  [668] Python - block insets help with documentation - (2006-04-04)
  [242] Satisfaction of training - (2005-03-11)

Q907 - Object Orientation and General technical topics - Object Orientation: Design Techniques
  [2523] Plan your application before you start - (2009-12-02)
  [2501] Simples - (2009-11-12)
  [2380] Object Oriented programming - a practical design example - (2009-08-27)
  [2327] Planning! - (2009-08-08)
  [2170] Designing a heirarcy of classes - getting inheritance right - (2009-05-11)
  [2169] When should I use OO techniques? - (2009-05-11)
  [1538] Teaching Object Oriented Java with Students and Ice Cream - (2008-02-12)
  [1528] Object Oriented Tcl - (2008-02-02)
  [1435] Object Oriented Programming in Perl - Course - (2007-11-18)
  [1224] Object Relation Mapping (ORM) - (2007-06-09)
  [1217] What are factory and singleton classes? - (2007-06-04)
  [836] Build on what you already have with OO - (2006-08-17)
  [831] Comparison of Object Oriented Philosophy - Python, Java, C++, Perl - (2006-08-13)
  [747] The Fag Packet Design Methodology - (2006-06-06)
  [656] Think about your design even if you don't use full UML - (2006-03-24)
  [534] Design - one name, one action - (2005-12-19)
  [507] Introduction to Object Oriented Programming - (2005-11-27)
  [236] Tapping in on resources - (2005-03-05)
  [80] OO - real benefits - (2004-10-09)

W512 - Web and Intranet - Site Design Aspects
  [2214] Global Index to help you find resources - (2009-06-01)
  [1598] Every link has two ends - fixing 404s at the recipient - (2008-04-02)
  [1353] Mood shots - (2007-09-16)
  [1054] UK legal requirements for your commercial web site - (2007-01-27)
  [1015] Search engine placement - long term strategy and success - (2006-12-30)
  [918] Databases needn't be frightening, hard or expensive - (2006-11-08)
  [859] Put the answer in context - it may be printed - (2006-09-08)
  [823] An excellent use for a visitor count? - (2006-08-05)
  [795] Remember a site's non-technical issues too - (2006-07-07)
  [718] Protecting images from theft - (2006-05-12)
  [649] Denial of Service ''attack'' - (2006-03-17)
  [556] Colour doesn't have to mean colourful - (2006-01-06)
  [510] Dynamic Web presence - next generation web site - (2005-11-29)
  [391] One mans pleasure is another mans poison - (2005-07-26)
  [352] Improved mining techniques! - (2005-06-19)
  [345] Spotting a denial of service attack - (2005-06-12)
  [319] Accommodation and landing pages - (2005-05-21)
  [288] Colour blindness for web developers - (2005-04-22)
  [229] A fortunate accident - (2005-02-27)

Back to Bounce, bounce, bounce

Previous and next or Horse's mouth home

Forward to Getting rid of people - hotel techniques

Too busy to blog it - but it's great (mostly)
The HTML++ Metalanguage
Java 6, Apache Tomcat 6.
Getting rid of people - hotel techniques
Maintainable code - some positive advice
Bounce, bounce, bounce
Bang! Train campaign hits home
Call for appropriate train services - Swindon, Bristol, Bath, West Wilts, Severn Beach etc
Sending an email from Python
Nested exceptions in Python