<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Good coding practice (article)</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1476" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi, </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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 ;)</FONT></DIV>
<DIV><FONT face=Arial size=2>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..</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2><A
href="http://pear.php.net/manual/en/standards.php">http://pear.php.net/manual/en/standards.php</A></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I personally cant handle the <!--StartFragment --><FONT face="Times New Roman" size=3> <FONT
face=Arial size=2>`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`.</FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial size=2>Perhaps that might offer some more pointers,
...e</FONT><FONT face=Arial size=2>ven then, code commenting , how often
& how verbose is another fight you can't win :D</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Regards,</FONT></DIV>
<DIV><FONT face=Arial size=2>Simon Wheeler.</FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV>----- Original Message ----- </DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=Ady@kiltotter.com href="mailto:Ady@kiltotter.com">Adrian Gould</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=phpwestoz@lists.linux.org.au
href="mailto:phpwestoz@lists.linux.org.au">phpwestoz@lists.linux.org.au</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, January 05, 2005 5:52
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> [PHPwestoz] Good coding practice
(article)</DIV>
<DIV><BR></DIV><FONT face="Trebuchet MS, Verdana, Helvetica, Arial"><SPAN
style="FONT-SIZE: 12px">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: 11px"><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 "good coding" principles?<BR><BR> 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> 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> 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). <BR><BR> 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).<BR><BR> 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> </BLOCKQUOTE></BODY></HTML>