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
