My personal favorite is the Hungarian Notation convention /cough, cough - donno why / where the first few characters/letters describe what kind of variable are we talking about, and uses camel case later on:
examples:
bBusy : boolean
cApples : count of items
dwLightYears : double word (systems)
fBusy : boolean (flag)
nSize : integer (systems) or count (application)
iSize : integer (systems) or index (application)
fpPrice: floating-point
dbPi : double (systems)
pFoo : pointer
rgStudents : array, or range
szLastName : zero-terminated string
u32Identifier : unsigned 32-bit integer (systems)
stTime : clock time structure
fnFunction : function name
The main thing I don’t like about Yii coding is the _ prefix for private fields/vars, it was useful in the PHP4 days where we didn’t have modifiers like “private”, “protected” etc. but now it’s ugly.
A coding standard is not about one’s preferred way of writing code. I prefer tabs over spaces, but I configure my editor according to the project choice. And when I code in Perl or C++, I don’t name my variables the same way as in PHP.
And that’s the same way a teacher can remove points for extra brackets. If she defined before the exam the coding standard that would apply, then you have to follow the rules. Even if you think the rules could be better.
With Yii, there’s one situation where it’s difficult to write code as you’d like. If you use scaffolding and don’t want to follow its default style, then you have to reformat the files. BTW, the generated HTML for CRUD is quite poor, with very low semantics.
That’ll always be the case with scaffolding or other kinds of pre-generated code, it’s not limited to Yii. As you can see from this thread (and probably many others like it all over the web), even proponents of strict coding styles find it hard to agree on a standard.
I can’t agree. Of course there isn’t one standard to rule them all. But that doesn’t mean a project doesn’t have to chose a standard.
And how many PHP projects don’t put spaces around operators? No space either after if/foreach/…? I don’t know any other than Yii. Some basic part of the PHP coding style are a de facto standard. So Yii’s style is completely different from PEAR, Zend, Drupal, ezComponents, CodeIgniter, Kohana, Symfony… Now suppose that one company/developper out of five hates to code with so strange a style…
Here is a quote from Paul Jones, in the first 2009 article of the famous "PHP advent":
I took a look at PRADO after it won the Zend PHP5 coding contest (2005, I think). My first impression was that the author spent a lot of time coding with Microsoft VC++ (and/or C#) because of the similarities with the style used in MFC (Microsoft Foundation Classes). Coming from a similar background, I found myself at home with Yii from the start. You see a lot of similarities in style in Yii with other programming languages such as Java. Zend was a bit slow moving PHP toward object-oriented programming and has come a long way in recent years. But, the Zend coding style is very much like C, a language dating back to the seventies. Yii is innovative in many ways from a PHP standpoint because of the authors rich experience with other languages. I see no reason in changing the style, but it should be documented more thoroughly in a style guide.
There is a decision behind this. In particular, the CComponent class allows for read/write ‘properties’ that infers from getter and setter methods. This is done using __get and __set magic methods. Thus, having the same var name as the property name will nullify the getter and setter methods. In particular, if at point in future the var needs to become a public properties, backward compatibility can be maintained (e.g. any derived class that access the protected var directly will still be ok).
Thank you guys. Yes, we really hope to someone can help us to improve the generated HTML code. If you have suggestions on how to improve particular code fragments or the entire templates, please write to me. Thanks!
Hmm, i wonder if it would make sense to manage that with Themes. My guess is, that there will be also a lot of different opinions on what is “good markup” . If we extend Themes a little and add CRUD creation to them, Yii could be bundled with different Themes for different tastes. At the crud command we could specify a theme to use for CRUD.
I agree, I think the ‘ideal’ solution to the whole issue of adding default functionality/having useless code that people have to edit anyway would be to have a range of templates/themes that users can choose (an extra option in the crud command) from. These templates/themes should range from extremely simplistic to lots of fancy things. Regardless of the users choice it should produce semantic, valid code.
It would be an interesting project. Unfortunately I don’t have the time to contribute though.
+1 for the adding of spaces for legibility. I do not aree with Qiang’s argument of easier search without whitespace. Even if you run into whitespace issues when searching (I’d love to see an example), regular expressions are your friend.
The entire idea of code that is easily readable to is lessen the amount of time anyone has to look at it when you are debugging or modifying it. When you’re writing it in the first place, you probable know what you are doing. But, especially in an open source project, others will come and precious time is wasted when you have to decipher a spaceless line of characters.
Also, there is a severe discrepancy in Yii’s code, concerning the argument of “typing few characters”.
Every associative array I see in the Yii source is built up like this:
$arr=array(
'foo'=>'bar',
'apple'=>'orange', // note the comma
);
So no extra spaces, but always an extra comma because you know you’ll forget to add it when you want to add another line to the array. The same goes for adding lines of code to a block statement. Curly brackets are your friend, and adding them even on single line statements will prevent others from introducing bugs.
So yes, Yii could do with some form of agreement on spaces and bracketing. Don’t know if it should be a complete coding standard, but sensible use of whitespace, comma’s and brackets would be welcome.