<HTML>
<HEAD>
<TITLE>Good coding practice (article)</TITLE>
</HEAD>
<BODY>
<FONT FACE="Trebuchet MS, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>Hi everyone<BR>
<BR>
An article that I found recently on PHPnoise has some good insights to coding practice ( <a href="http://www.phpnoise.com/tutorials/4/1">http://www.phpnoise.com/tutorials/4/1</a> ).<BR>
<BR>
Here is an extract (the second page of 4) that covers why worry about coding carefully.<BR>
<BR>
What are your thoughts?<BR>
<BR>
I aim to use this as a set piece of text for my students this semester.<BR>
<BR>
Ady<BR>
<BR>
</SPAN></FONT><FONT FACE="Tahoma"><SPAN STYLE='font-size:11.0px'><B>Why do I need to worry about it?<BR>
</B> 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 &quot;good coding&quot; principles?<BR>
<BR>
&nbsp;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.<BR>
<BR>
&nbsp;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.<BR>
<BR>
&nbsp;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 &quot;&lt;&quot; 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). <BR>
<BR>
&nbsp;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 &quot;;&quot; on line 3,204 of 5,000 which keeps &quot;magically&quot; deleting itself).<BR>
<BR>
&nbsp;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.</SPAN></FONT>
</BODY>
</HTML>