NYCPHP Meetup

[Morgan Craft]

go with camelCase.  very easy to read once you start working with it 
consistently.  And if you use Trac for your ticketing system the 
built-in wiki functionality allows for camelCasing (might be a plugin) 
and you can help integrate documentation of projects with your code 
repository.

now if we could just get rid of that Hungarian notation.....



edward potter wrote:
> so simple, so sweet!  :-) ed
>
> $firstname
> $lastname
> $address
> $city
> $state
> $zip
> $phone
> $fax
> $email
>
> spaces? ugly
> dashes? ugly
> underscores?  ugly
> camel?  weird!  :-)
>
> :-)
>
>
> On 9/27/06, tedd <tedd at sperling.com> wrote:
>   
>> At 6:34 AM -0400 9/27/06, Peter Sawczynec wrote:
>>     
>>> So I'm just asking for an opinion, do you deal with spaces in variables?
>>> Never use spaces?
>>>       
>> Peter:
>>
>> Opinions?
>>
>> It depends upon what _you_ want to see in _your_ code, unless you're
>> working with a team. I've seldom worked with a team, so I'll leave
>> that to others to comment.
>>
>> I use mixed case (i.e, pageNum). I try to keep my variable names
>> short and to the point. I never use spaces -- besides, spaces aren't
>> consistently allowed anyway.
>>
>> I try to keep the variable name the same across different languages
>> (i.e., $pageNum - php, pageNum - MySQL).
>>
>> With counters and other temporary/short-scope variables I use i, j,
>> k, l (left over from my FORTRAN) days, which is one of the reason I
>> use lowercase. Likewise, I never use i, j, k, l for anything but
>> short-scope variables.
>>
>> You say: "To me, spaces is what makes data names human readable."
>>
>> Not for me, spaces mean to me that these data names aren't variables.
>> Just give me a variable that looks like a variable; and a name has
>> some relationship to the data they hold; and I'm happy.
>>
>> If you want to see a problem with names, trying reviewing some of the
>> constants that Apple has for it's development (I'm sure they are not
>> alone) -- they are approaching the limits for name length.
>>
>> Another consideration, while I've never had to do it for php, I've
>> worked with variable names that were further identified by their
>> prefix, such as gPageNum -- meaning that it was a global variable. If
>> you have a very large project, you might want to consider using a
>> prefix for naming, such that you would know where the variable
>> originates.
>>
>> Chris Shifett (in his book Essential PHP Security -- in my mind,
>> required reading) used "$clean" for variables that were sanitized --
>> not a bad idea. I would consider expanding that idea by adding a "c"
>> to the front of a sanitized variable, such as $cPageNum.
>>
>> In any event, whatever scheme you adapt, you're the one who will have
>> to live with it. The more consistent and easy for you to identify and
>> work with, the better.
>>
>> A long time ago, a mentor once told me "Be careful picking your
>> religion, because you're the one who has to live with it." Wouldn't
>> it be interesting if what we believe is what it is?
>>
>> tedd
>>
>> --
>> -------
>> http://sperling.com  http://ancientstones.com  http://earthstones.com
>> _______________________________________________
>> New York PHP Community Talk Mailing List
>> http://lists.nyphp.org/mailman/listinfo/talk
>>
>> NYPHPCon 2006 Presentations Online
>> http://www.nyphpcon.com
>>
>> Show Your Participation in New York PHP
>> http://www.nyphp.org/show_participation.php
>>
>>     
>
>
>