I can only but concur to what has already been said.The other thing is that it would be nice to have a coding convention that can be applied by the major tools - netbeans, eclipse, etc.
So that we don't have to bother too much.I must confess that I use pretty printing a lot and was unable to completely apply the coding convention to netbeans.
Typically
}else
{
instead of
}
else
}
I tried to find out a good pretty printer for PHP too but didn't succeed
so far.
Le 05.05.2011 19:31, Yannick Warnier a écrit :
Well in general in 1.8 we apply the naming convention strictly to files, functions and variables, but not to classes names. It's a bit weird, I know, but I'm flexible about it (in 1.8, that is) as long as it's not into the core or there's no dependency on that, and mostly because in the beginning we didn't have a strict convention for that (maybe that started in Claroline before 2004, I don't know) so there was pretty much nothing to do about it if you didn't want to risk the integrity of the code every time (at that time variables and functions had very crappy names very similar to one another so it was really difficult to ensure you were modifying only the ones you needed). What really matters to me (again, in 1.8) is that variables and functions follow that logic. These are really the important parts in terms of readability (every time you fix a bug or develop some new thing, you probably open only 3-4 files, but you do read a lot of variable and function names). Now is a great opportunity to perfect the coding conventions with explanations as to why we chose this or that (and write them down on the wiki so we don't ask ourselves the same thing in 4 years from now). Cheers, Yannick El jue, 05-05-2011 a las 15:56 +0200, Philippe Van Eerdenbrugghe escribió:I was just asking , we are starting from scratch so we are evaluating lots of decisions which have been made previously and we do not understand withtout hints. It's not that difficult to go for underscore notation but if it's not completely forced we would have chose to keep the same notation for file names and class names. To answer your question, the camelcase to underscore mechanism is a mechanism of the autoloader which is responsible for finding the right file based on the class name. Since we plan to mirror the namespace segment with folders in our apps, it would have been natural to use CamelCase for ou class files. The CamelCase to underscore function which we can find in Utilities has some drawbacks (like handling numbers, or transforming "XMLReader" to "x_m_l_reader" ) and it has been chosen in almost all php libraries to name the class files in CamelCase so I was asking why Chamilo chose another path. I also agree that underscore notation is more readable but my question arose from the fact that we change the convention between class name and file name Systho Le 5/05/2011 15:36, Yannick Warnier a écrit :Does someone sees a problem if an optional app (not the core) uses its own coding convention ? We (the claroline team) are thinking to follow this convention for naming the classes : http://groups.google.com/group/php-standards/web/psr-0-final-proposal except for the ones loaded by the framework (Notably the data manager, the manager and the components) Actually I do not understand the reason for all the CamelCase-to-underdscore mechanism so if someone can enlight me on this subject it would be greatly appreciated.Could you detail "all the CamelCase-to-underdscore mechanism" so that I understand it better? In general terms, in the 1.8 branch, we decided to use underscore (also called minor camelcase) because a study (I don't have the reference but I know it was around 2004) demonstrated that, for non English-natural-speakers, it was far easier to_read_text_separated_by_underscores than ToReadTextUsingMajorCamelCase. The example above kind of proves the point without the need for the study (I don't think any of us is a natural English speaker). Wanting to have the major possible easiness at entry point for developers, we decided (I'm not talking about the current team) to go for "lower" camel_case and we've stuck to this since then. I'm not sure these are still the conventions in 2.0, but I'd follow whatever is set as a convention right now and I agree with Hans that it would be a really bad idea, although technically I wouldn't put it as an exclusion condition to your participation in Chamilo 2. Yannick _______________________________________________ Dev mailing list Dev@lists.chamilo.org http://lists.chamilo.org/listinfo/dev_______________________________________________ Dev mailing list Dev@lists.chamilo.org http://lists.chamilo.org/listinfo/dev_______________________________________________ Dev mailing list Dev@lists.chamilo.org http://lists.chamilo.org/listinfo/dev
-- ____________________________________ Meilleures salutations Laurent Opprecht chat: laurent.oppre...@gmail.com blog: http://ciel.unige.ch/
<<attachment: laurent_opprecht.vcf>>
_______________________________________________ Dev mailing list Dev@lists.chamilo.org http://lists.chamilo.org/listinfo/dev
