programming standards

matjaz

a while ago i read a webpage explaining PHP programming standards [coding] for that company. i lost that url of course...

i would like to help me finding a good description of how should a team write the code so it is understandable to each other every second. i know some of you laughed to similar questions months ago... but that article was really good. not that it defined how to name variables, it also said how you should write IF sentences:

wrong:
if ($x==1)
echo "lala";

right:
if ($x==2) {
echo "lala";
}

of this:

wrong:
$x++;

right:
$x = $x + 1;

i know some of you will go "WHHHHHATTT" but i understand the purpose of the team who defined this for them self. it makes sense! there were 100 more of such things but as i said, i lost it.

anyone with such article or his own definition of coding?

tomhath

Are you thinking of the PEAR standards?

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

michael

I think pre and post increment is one of the most basic (hence, C++) functions and anyone who doesn't understand it should be pelted with steel plus signs.

Coding standards are what you make them. Decide a standardized way to do your work (usually the head or best programmers) and go with them.

Shop standards are merely that.

But they entail common (and mandatory) ways of naming programmes(filename), variables, functions, objects and methods.

They also say you should comment every lump of code over 3-4 lines. Explain what you're doing. Have a summary at the beginning of the programme.

I wrote an IDX programme, and the documentation (inline) was almost longer than the program. But I did it becasue I might not always be around for them to ask. I wanted them to be able to change some things on their own.

I hope this helps.

Develop your own. Don't use others, because they might not apply to what you need.

Weedpacket

Originally posted by michael
They also say you should comment every lump of code over 3-4 lines. Explain what you're doing. Have a summary at the beginning of the programme.

For any larger project (for some value of "larger") I'd go further and have additional developer documentation. Just as a house isn't built without a set of blueprints, write and keep current documentation that describes what the software does, how it does it, why it does it that way, where to make what sorts of changes, and who to blame if it all goes pear-shaped 🙂.

In fact, if the design documentation is clear and well-structured enough, the actual coding is often then a P.O.P by comparison, because the majority of the hard work's already been done.

If the design is altered partway through, don't just forget what it used to be, but record it for posterity and explain the change.

This will help prevent new developers from getting lost or shocked, and give them a better handle on the big picture.

All that would go in the records for each project of course - available for mining at a future date when a similar project comes up. (Following on from that of course is the code library.)

And one thing that's caused me too much hassle in the past is a lack of proper source control. These days I do a whine/pout if a SC protocol isn't in place - whether it's CVS, or patch pumpkin, or a dictatorship.

As for the previous discussion, it's here.

jc94062

I have to agree that standards tend to be enforced by whichever company you work for, to a degree. (I still refuse to write isSet as opposed to isset for example, I also go though huge chunks of code when rewriting it to use while {}and if\else if\else as opposed to while\endwhile, if\endif, but thats just personal preference).

As your continually editing and added code to a project, or set of projects all the code tends to look the same and that tends to be refelected in what you right.
Also, if you start writing unreadable code with no comments you'll get some remarks about that pretty quick (ie: I have no idea what any of these functions do, put in comments).

As far as those examples go..

wrong:

if ($x==1) 
echo "lala";

right:

if ($x==2) { 
echo "lala"; 
}

I tend to right mine in the way you've called "right", purely because I then have the brackets should I want to add things. But the way at the top isn't wrong by any means, it works...
Therefore it can't be wrong.
You can also right them down as

if ($x==1):
echo "lala";
endif;

or something similar, I don't use those if\endif as a rule.

wrong:
$x++;

right:
$x = $x + 1;

Thats so absurb its just crazy
$x++;
$x=1;
$x=$x+1;

They all work, but the "worst" one is the one thats someones claimed is right, its just "ugly" code, probably slower as well, but don't hold me to that.

I could also see how someone would call ++$x wrong, as its also crazy in my opinion, but it still works, albeit its something I've never had to use, nor even seen used.

Weedpacket

Originally posted by jc94062
I could also see how someone would call ++$x wrong, as its also crazy in my opinion, but it still works, albeit its something I've never had to use, nor even seen used.

I commented on this in the previous thread on this subject; I'd add to my comment there the whisper that "++$x" is a hair faster, but the difference would be piffling (if detectable).