Suggest pear style for your code. I stick with Ruby'ish style for naming my
sql stuff.
table : locations
field: location
Sticking with something that simple can save you DAYS of headaches~!
seems to work out well.
On Mon, Apr 27, 2009 at 7:07 PM, David Krings <ram...@gmx.net> wrote:
> li...@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
>
--
IM/iChat: ejpusa
Links: http://del.icio.us/ejpusa
Follow me: http://www.twitter.com/ejpusa
Karma: http://www.coderswithconscience.com
_______________________________________________
New York PHP User Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/show_participation.php
