NYCPHP Meetup

[Kristina Anderson]

Very interesting topic.

My thoughts.

Name functions and variables meaningfully so that you enhance readability.  Don't be afraid 
of "too long" names, within reason.

Indenting is important but not worth going insane over.
Camelcase leads to frustrating typing errors and is just silly in most cases.  Use all lower, or 
even underscores are less annoying.  But be consistent.  Or try to be.

Lastly anyone who tries to impose THEIR conventions on you is to be ignored.  This is all 
about you, and what widget YOU think is easiest to use.  Worrying about where to put a 
curly bracket is not worth it -- put it where you like it!  As long as the code works you are 
golden.

Happy coding!! :)

Kristina

> 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
> 
> _______________________________________________
> New York PHP User Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
> 
> http://www.nyphp.org/show_participation.php
> 
> 

-------------------
Kristina D. H. Anderson
PHP Application Developer
"Building a Better Tomorrow, One Line of Code at a Time"
347 254 2810