[PHPwestoz] Good coding practice (article)

[unknown at firepages.com.au]

Good coding practice (article)Hi, 

You only need to look at the php internals lists to see what type of religious war you are stepping into with variable naming standards ;)
There are several sets of coding standards out there , but the only one that really has a any reference to the php group (and loosely so) would be the PEAR coding standards..

http://pear.php.net/manual/en/standards.php

I personally cant handle the  `one true brace` convention but if I wanted to write for pear ... I would have no choice , so its at least one area within the PHP community  where coding standards are `enforced`.
Perhaps that might offer some more pointers, ...even then,  code commenting , how often & how verbose is another fight you can't win :D

Regards,
Simon Wheeler. 




----- Original Message ----- 
  From: Adrian Gould 
  To: phpwestoz at lists.linux.org.au 
  Sent: Wednesday, January 05, 2005 5:52 PM
  Subject: [PHPwestoz] Good coding practice (article)


  Hi everyone

  An article that I found recently on PHPnoise has some good insights to coding practice ( http://www.phpnoise.com/tutorials/4/1 ).

  Here is an extract (the second page of 4) that covers why worry about coding carefully.

  What are your thoughts?

  I aim to use this as a set piece of text for my students this semester.

  Ady

  Why do I need to worry about it?
  So why should you care? You've written lots of code, you know what it's about, and you don't have any trouble. What's the big deal? Why should I go to the trouble required to apply "good coding" principles?

   Essentially, if you apply these principles, then you will find your own work easier to read, easier to fix (for those of us who don't always get it right the first time - not that you have this problem), easier to go back to in six months to maintain, more robust, and anyone else who has to deal with your code stands a better chance of understanding it. Let's take a (brief) closer look at each one to drive it in.

   Legibility - the code which you write (and this applies to the output it generates too) needs to be set out in such a way that you can read it. If you read a lot of other people's source code, then you will have noticed that sometimes it is a lot easier than others. A simple piece of code becomes very difficult to read when it's all cramped together with useless variable names and confusing logic. As for a complicated piece of code, you can forget it... Just because you know what something you've written does is no excuse for sloppy presentation.

   Robustness - here I'm mainly talking about programs that accept input. Users (bless their little hearts) are like children; no matter how clearly and carefully you explain what they have to do to use your program someone always manages to do something which they aren't supposed to, be it putting in illegal characters (like "<" for html input forms) or pressing the wrong buttons. You need to try and make sure that your program is as forgiving as possible and check for these little lapses that users make. It will make your program much more popular because it will work (even if it's just putting out error messages which make sense). 

   Debugging - sure, somewhere out there it's possible that a person writes perfect code every time, first time. It does what they expect, and there are no problems. For the rest of us, however, debugging code is just part of the normal routine. The easier to read and more logical the construction of your code, the easier it should be to find that niggling error (like that missing ";" on line 3,204 of 5,000 which keeps "magically" deleting itself).

   Portability and Maintainability - it's not always you who has to work with your code, and even if it is, what happens six months or a year after you wrote it? If it's a simple piece of code, ok, but the bigger the project the more difficult it is to get a feel for it afterwards. Try to keep this in mind when you're writing the code, and plan the logic and layout of your code in as comprehensible a way as possible. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux.org.au/pipermail/phpwestoz/attachments/20050106/f532fa10/attachment.htm