RE: Variable case
Traditionally,
FOO is read as a global literal constant, you cannot change this and is
available everywhere and is intended to be used both inside and outside
the project.
$FOO, $foo, $Foo can be read in wildly different ways. By and large i
see:
$FOO as a global variable for a specific application. Usually because
you can't pre-initialize it in the class or without doing something
before hand, and typically you don't change these, they're a
honor-system read only.
$foo is a local variable, something that only exists within the current
scope and goes away later.
$Foo i rarely see, though usually it means its important for some
reason, such as some sort of glue between a function and something
outside the function, or a reference to something within another
something-something. The point is it doesn't quite adhere to the
locality of $foo but isn't as off limits and viewable as $FOO; I like
to think of it as akin to 'protected' in OOP terminology. Occasionally
I see important public methods starting with a capital and using camel
notation, such as functions that should be called during shutdown or
startup prior to any other calls.
(Aside, this is one reason i like how perl differentiates uses with $,
#, and @, it gives me a better understanding of what context it should
be used and read in)
So, yes, traditionally, case does have an impact on the implied meaning
of what a variable does, where it is used, and so forth. You can have
case insensitivity when there are language constructs that strictly
limit how a variable is used. 'local refererence constant $foo;
global copy variable $FOO; bridging constant local $Foo' etc etc
Re: Function case
1) It would be nice to have consistancy throughout the language.
Previously, classes were stored in all lowercase, and later this was
changed to match the declared case. (Thank god!)
2) You know what to expect when you are looking for a function or
declared identifier. I declare it as 'myFunc', and its stored as
'myfunc,' but i naturally expect it to match the way I wrote it. Now I
have to write case insensitivity into determining if its the function i
want, and to verify that whatever information i'm storing is, indeed
correct? Rubbish i say.
If i call it myfunc, MYFUNC, or MyFuCn, i expect to be able to refer to
it only as how i defined it. Making it 'fuzzy' sounds sloppy and
doesn't, in my opinion, promote good coding habits. I'd much rather
have an error handler catch a programming mistake than the computer
assume it knew what i meant.
3) If i call it MYFUNC, i'm capitalizing it for a reason. Calling it
as myfunc() is not what i am expecting to look for in code if i go
reading it over and downplays the importants that this function must
server. hack_together_sql() has a different authority to it than
Hack_Together_SQL(). The former tends to imply that its a hack and
shouldn't be relied on, the latter that it is some complicated
necessity to be used with caution, and the importance of both of those
meanings should always be present in the writing of them.
Re: maintainance nightmare
You've not seen some of the 'professional' PHP code out there you can
buy? Half of them don't even spell variable names right, let alone
adhere to any sort of standard or continuity. I'd much rather pick up
any code and understand the intent of it instead of being able to skip
pressing the shift key.
Of course, thats just how I see things.
>> Stay informed about: array() VS Array() 
FAQ
Search
Profile
Private Messages
Log in
