NYCPHP Meetup

NYPHP.org

[nycphp-talk] Best practices for naming conventions & coding style?

David Krings ramons at gmx.net
Mon Apr 27 19:07:33 EDT 2009


lists at nopersonal.info wrote:
> Hi everyone,
> 
> I've been making steady (if slow) progress with my understanding of
> PHP/MySQL, but now that I'm finally starting to do more complex things,
> I find that I really need to figure out a consistent naming convention &
> coding style. I've read several articles on the subject and they all
> seem to be different.

Because in that regards, if you ask five people you will get seven opinions. 
Just watch the responses. ;)
It is good that you realized that and took action. That is the biggest step 
forward.

> Is there a de facto professional standard, or is it just whatever you
> personally prefer (provided that you're not part of a larger team with

Not that I know of, unless you are in a particular camp. That means the DotNet 
folks use the Microsoft bible of coding and often enough violate their own rules.

> specific guidelines)? So far I'm doing the following:
> 
> -Functions are all lower case, no numbers, underscores used to separate
> words
Some use CaMeLcAsE for that, the point is the same, pick what you can read better.

> -Variables (same as functions--should they be different?)
Yep, I'd handle them the same way. As important is that you give them 
meaningful names. I once had a coworker who used his first and last name as 
variable names for everything. He'd even write code to change the type from 
string to integer. Don't do crap like that. Modern IDEs have 
autocomplete/intellisense and there is really no reason to be that 
self-centered. Also, I find a $counter to be way clearer than a $i, although 
the $i, $j, $k, $l ... approach is very common.

> -Constants and MySQL reserved words & functions are all upper case
With MySQL reserved words you mean SQL? Yep, I do the same.

> -Classes... I'm not that advanced yet!
Same here...also applies to objects. I do use some for handling zip files, but 
that is limited to copying sample code.

> -Plenty of comments to help me remember what the code was for
Exactly! What I do is write the comments first and ideally do it as detailed 
as possible. Then I fill in the code, which for me is the easiest way.

> -Tabs for indentation
Yep!

> -No echoing HTML code except where moving between it and PHP is too messy
See, here I differ, but that is just me. I rather echo HTML than deal with the 
opening and closing tags, which I find confusing in a sense that I have a 
tought time finding where PHP is and where HTML is. Again, this is purely 
personal preference and if you are OK with the way you do it, stick with it, 
it is faster.
Also, keep in mind that you should separate display from process. So first do 
all the PHP magic and stick everything ready to go into variables, then make a 
big line and below that start the output. On very rare occasions I had to 
divert from that, but I am sure that is simply because I'm inexperienced and 
that there is a better way.


> -Stick with single quotes for string literals where there are no
> variable substitutions and/or where there ARE variable substitutions,
> but where using double quotes would necessitate lots of escaping

Uhhh, you may want to dig through the archives of this list. Some time ago we 
had a very passionate discussion about it and if I recall correctly, everyone 
was right a bit and wrong a little.


> Two things I've read about that I don't do are 1.) put spaces before &
> after the string concatenator,
Same here, after all, it is a concatenation, so why throw spaces in there.

  and 2.) keep my opening/closing braces on
> their own lines.
I do it the same way, but I can see that it adds more white space and thus 
makes things easier to read. It also separates "code" lines from "control 
characters", if you know what I mean. Again, do what works best for you, the 
PHP interpretor doesn't care either way.

> 
> //I find it much easier to read:
> 
> if ($foo == '') {
>     echo '<p id="message" class="error">'.$message.'</p>';
> } else {
>     echo '<p id="message" class="success">'.$message.'</p>';
> }
> 
> //Than:
> 
> if ($foo == '')
> {
>     echo '<p id="message" class="error">' . $message . '</p>';
> }
> else
> {
>     echo '<p id="message" class="success">' . $message . '</p>';
> }
> 
> Are any of the things I'm doing/not doing a major no-no? It's not too

I know it is just an example, but I'd double or triple the commentary in the 
code above. A one liner may be OK for you, but others will appreciate the 
detail and what is clear to you today may not be that clear in six months from 
now.

> late for me to unlearn bad habits, so I'd really appreciate any advice
> you could give.

I think with writing this all up you did yourself the best favor. Now stick to 
your own coding guidelines and add lots of commentary. Again, modern IDEs help 
out with that, because you can craft templates for if..else or switch 
statements or new files and already have the basic commentary lines in place. 
You are definitely on the right track.

David




More information about the talk mailing list