David Krings wrote:
>> -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.
Re your friend, yikes! I know what you mean about using $counter. I
figured out that $i or $n stands for an integer, but it still throws me
off sometimes when I see something like $l in someone's example code
(below)... what is the "l" supposed to stand for? Or does it depend on
the context? I still have to "translate" code by reading out loud to
myself line-by-line and noting what it does in a comment. Here's a
snippet of some example code I got somewhere for exporting to a CSV file
where I added my own translation:
<snip>
//get results form db
$results = mysql_query("SELECT * FROM foo") or die(mysql_error());
//$out?? Maybe $output?
$out = '';
//retrieve field info from table--mysql_list_fields() appears to be
deprecated?
$fields = mysql_list_fields('db_name','table_name',$conn);
//get the number of MySQL fields in the table and assign that value to
$columns
$columns = mysql_num_fields($fields);
//set counter to 0, as long as it is less than the number of $columns,
increment it by 1
for ($i = 0; $i < $columns; $i++) {
//name each field--why $l?
$l = mysql_field_name($fields, $i);
//huh?
$out .= '"'.$l.'",';
}
<snip>
Obviously I didn't quite get what every line did, but I usually figure
it out on my own (eventually).
>> -Constants and MySQL reserved words & functions are all upper case
> With MySQL reserved words you mean SQL? Yep, I do the same.
Yep, I meant SQL. I understand the distinction, but I guess in my head
the two are interchangeable since MySQL the only thing I'm remotely
familiar with. :)
Oh man, speaking of reserved words, a couple of weeks ago I was stuck
for almost half a day trying to figure out why one of my queries kept
throwing errors (it doesn't help that the error messages are so darned
enigmatic). Anyway, after about 6 hours of picking at the query trying
to figure out why it refused to work when others with the same syntax
worked fine, something that had been nibbling at the edge of my
consciousness finally rose to the surface--I had named one of the fields
in my table "desc" (for description). I was like, "Wait a minute...
desc... DESC... OMG, that's a reserved word--what a stupid newbie
mistake!!" *headdesk, headdesk, headdesk* Suffice it to say that I won't
be making THAT mistake again.
> 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.
Sounds great--I'll definitely start doing that.
>> -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.
Hehehe, sounds interesting. I'll have to check that out.
>> //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>';
>> }
>
> 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.
Oh yeah, believe me I do! I just left out additional comments for the
sake of saving space here.
>> 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.
I'm (somewhat) embarrassed to admit in present company that I do most of
my PHP in Dreamweaver as I know most of you probably think that's pretty
lame. But I'm comfortable with DW, you know? Most of the PHP I do
involves working around the HTML in web pages, and I have my own
snippets for stuff I use frequently. I know how to hand code, but seeing
as how may keyboarding skills have always been deplorable, I find it
much easier to use DW's split mode (code on one side, wysiwyg on the
other) to navigate through the code. Not only that, but CS4 has some
nice new features for working with code. Aside from code completion, I
don't use any of the PHP stuff that DW provides (server behaviors,
bindings. etc.) as the code it creates confuses me and puts stuff where
I'd rather not have it (I'm a control freak when it comes to
understanding what's going on). IOW, I basically use DW as a glorified
text editor.
I have a copy of phpDesigner, but I don't use it as much as I probably
should. I guess I should explore it more as it might have features I'm
unaware of that'll save me time (especially where debugging is
concerned). I tried a couple of open source IDEs, but didn't stick with
any of them. I hate anything Java-based because of the system resources
it eats up, so Eclipse was out (though I have a strong front-end coding
background, my primary job function is that of graphic designer, so I
tend have a ton of other resource hogging things running in the
background most of the time). Komodo Edit was nice, but missing many
features of the IDE version...Since I'm still not experienced enough to
be able to take on the heavy-duty back-end stuff, I don't really feel
comfortable trying to justify the purchase price of something like that
to my employer.
Okay, I've prattled on far too long! Thanks for the advice.
Bev
_______________________________________________
New York PHP User Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/show_participation.php
