Why is this? What is the practical reasoning behind this visually not all too appealing convention?
If we lived in a time where the classes did not have visibility such as private, protected and public, I would understand that one could prefer to use _ to “move” private class variables “out of the way”, essentially creating their own little namespace in a class as a substitute for visibility. But this is not where we’re at today.
If it’s a matter of making it apparent which properties are private, I don’t wee why we would do this especially for private properties, when not handling protected properties in a special way to be able to easily distinguish them as well.
Also, normally one uses a decent IDE, in which case the IDE should indicate members’ visibility with some coloring or icon.
Personally I would not want to prefix with _, but at the same time i do want to follow conventions. I just have a hard time seeing the reason behind this, but perhaps someone can give me a good one?
You can follow conventions only if you develop public extension. I usually don’t prefix private vars. This convention is from PHP4 that has not variables visibility restrictions in classes.
as Nemoden already mentioned it’s mainly from ‘the old days’ where you weren’t able to define a variable/method as private or public. It was kind of a little visual hint for a programmer saying “you can call this but you know you shouldn’t”. Not to be mistaken with a method with two underscores.
Today the compiler/interpreter of course knows what is private, protected or public but it’s still a nice convention for someone uninvolved reading the code, because he directly sees if a private (internal) variable is used or not.
Btw: some people are still reading code without an IDE
But still, since this is a remnant from old times lacking visibility, why does Yii even care about it considering it’s built for PHP5 which supports visibility? Old times are old times, new times are now, so to speak.
And heck, assuming the code is well architectured (which Yii is), visibility shouldn’t be of that much concern since what you read is the API and not a bunch of property assignments.
I guess it’s simply a matter of the author thinking it’s nice to be able to see what variables are private and which ones aren’t, in plain text/sight.
It’s quite inconsistent though, in that only private properties are indicated with a prefix and protected ones are still looking the same as public ones. Presumably because the main things to distinguish in the old days were public vs private ones.
If you have a private/protected property often you have a getter and setter method, that should be called as the property. So for avoid confusion, the property is _property, so if you call $object->property there are no doubt that will be handled by the getter/setter.
About protected, I could not find a protected var in the framework code, so I don’t know what is the convention, personally I use the underscore even for protected.
