http://www.doctrine-project.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=fixVersion+%3D+%222.0-RC1%22+AND+project+%3D+DDC+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC An XML representation of a search request en-us 5.2.7 850 21-02-2013 http://www.doctrine-project.org/jira/browse/DDC-274 Doctrine 2 - ORM <p>There are inconsistencies with some class and namespace names that include acronyms.</p> <p>Examples:</p> <p>Classes with upper-casing:<br/> ORMException, DBALException, OCI8Connection, etc.</p> <p>Classes with proper-casing:<br/> RunDqlTask, CliException, MySqlPlatform, etc.</p> <p>Namespaces with upper-casing:<br/> DBAL, ORM, Doctrine\DBAL\Driver\PDOMsSql, etc.</p> <p>Namespaces with proper-casing:<br/> Doctrine\Common\Cli, Doctrine\DBAL\Tools\Cli\, Doctrine\ORM\Id, etc.</p> <p>There is more proper-casing than upper-casing. IMHO, proper-casing is better as it's easier to read "SqlException" than it is to read "SQLException" (the "E" looks like part of the acronym), and things like "CLITask" can be avoided. <img class="emoticon" src="http://www.doctrine-project.org/jira/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/></p> <p>I discussed this a bit with Benjamin and Guilherme, and they were unsure and said that the whole team needed to reach consensus.</p> <p>I'm leaving the priority as "Major" because this should probably be fixed sooner rather than later to prevent compatibility breaks.</p> DDC-274

Class and namespace naming inconsistency

Improvement Critical In Progress Unresolved All Roman S. Borschel Glen Ainscow Sun, 24 Jan 2010 16:30:50 +0000 Sun, 31 Oct 2010 05:20:55 +0000 2.0-ALPHA4 2.0-RC1 1 1 <p>Increasing the severity and adding a fix version since this MUST be fixed before next release.</p> <p>I find this to be of rather minor importance. You're talking of compatibility breaks, but thats only the case if we intend to start being very nitpicky about the naming in the future. We are currently not, and we wont be, so not much risk of later breakage.</p> <p>We have a rule of thumb already: Acronyms up to 4 characters all uppercase, otherwise normal camelcase.</p> <p>Now, it is often a matter of taste what is an acronym and what not and also not all acronyms have a clear casing, prime example mysql.</p> <p>Being too nit-picky here is just a pain in the ass and we won't reach a common consensus anyway.</p> <p>Oh and we better dont start arguing about whats better to read because there is no chance of agreement. If you ask me I find SQLException better than SqlException. So here we go. Lets better not run down this path.</p> <p>No need to get upset, I'm only trying to help.</p> <p>I just thought that consistency is usually a good idea, either way.</p> <p>I have to disagree in that an acronym is an acronym, it's not a matter of taste, the letters either stand for something, or they don't.</p> <p>As for "mysql", only the SQL part is an acronym. So, MySQL or MySql.</p> <p>Close if you disagree.</p> <p>I'm not upset. What made you think so? Maybe I should introduce a <img class="emoticon" src="http://www.doctrine-project.org/jira/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/> every now and then.</p> <p>There's just no point in arguing about readability.</p> <p>Like I said, we do have a naming standard even if its not adhered everywhere. The standard is also not something we've made up ourselves because we try to avoid that. When we introduced namespaces, we talked about adopting either the Java or .NET naming standards. We opted for the .NET standards. And there its recommended to write acronyms with up to 4 characters all uppercase.</p> <p>I dont think there are too many violations of that in the code, probably Cli =&gt; CLI and some others but most of it looks ok to me.</p> <p>UPDATE: Maybe we can gather a list here in this ticket of violations? Cli =&gt; CLI would be one. MySql =&gt; MySQL another. "Id" is rather an abbreviation of Identifier and not an acronym, to me at least.</p> <p>It's not a case of getting anyone upset...</p> <p>But we should fix it and keep consistency of our codebase.</p> <p>@romanb We should all talk and reach a common sense.<br/> That's our last chance (last alpha) to get this consistency in.</p> <p>@Guilherme: We do have a naming standard since a year. You want to change the standard now?</p> <p>@Roman,</p> <p>Just a feeling I got. <img class="emoticon" src="http://www.doctrine-project.org/jira/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/></p> <p>This issue was more about consistency (indicated in the title) than moving to proper-case naming.</p> <p>I think it might be up to 3 characters in .NET, HtmlElement, System.Linq, etc. Anyway, not important. <img class="emoticon" src="http://www.doctrine-project.org/jira/images/icons/emoticons/wink.gif" height="20" width="20" align="absmiddle" alt="" border="0"/></p> <p>I agree that Id. is an abbreviation.</p> <p>There are some more violations. If you decide you want to change them, let me know and I'll compile a list.</p> <p>@Glen: Yes, a list would be great. I find it hard to be 100% consistent sometimes though because my taste conflicts with the rule. For example, I would prefer "Id" over "ID", especially since it comes directly after ORM "Doctrine\ORM\ID\..." would be a bit too much. But I would not like "Orm" or "Dbal" either. But I think in most cases we can clearly fix the inconsistency. Like CLI or MySQL or MSSQL (or should it be MsSQL?).</p> <p>Thanks for your help!</p> <p>We should probably create updated coding standards for Doctrine 2 also, since they differ quite some from Doctrine 1 due to the introduction of namespaces and such. I'll create a ticket for that.</p> <p>I'll do the list for you by tomorrow at the latest, just running out of time ATM.</p> <p>Id is correct, as mentioned above, so that would be fine. MsSQL is correct (Ms = Microsoft = abbreviation).</p> <p>Found some time ...</p> <p>Doctrine\Common\Cache\ApcCache -&gt; APCCache<br/> Doctrine\Common\Cli -&gt; CLI<br/> Doctrine\Common\Cli\Printers\AnsiColorPrinter -&gt; ANSIColorPrinter<br/> Doctrine\Common\Cli\CliController -&gt; CLIController<br/> Doctrine\Common\Cli\CliException -&gt; CLIException</p> <p>Doctrine\DBAL\Driver\PDOMsSql -&gt; PDOMsSQL<br/> Doctrine\DBAL\Driver\PDOMySql -&gt; PDOMySQL<br/> Doctrine\DBAL\Driver\PDOPgSql -&gt; PDOPgSQL<br/> Doctrine\DBAL\Driver\PDOSqlite -&gt; PDOSQLite<br/> Doctrine\DBAL\Logging\EchoSqlLogger -&gt; EchoSQLLogger<br/> Doctrine\DBAL\Logging\SqlLogger -&gt; SQLLogger<br/> Doctrine\DBAL\Platforms\MsSqlPlatform -&gt; MsSQLPlatform<br/> Doctrine\DBAL\Platforms\MySqlPlatform -&gt; MySQLPlatform<br/> Doctrine\DBAL\Platforms\PostgreSqlPlatform -&gt; PostgreSQLPlatform<br/> Doctrine\DBAL\Platforms\SqlitePlatform -&gt; SQLitePlatform<br/> Doctrine\DBAL\Schema\Visitor\CreateSchemaSqlCollector -&gt; CreateSchemaSQLCollector<br/> Doctrine\DBAL\Schema\Visitor\DropSchemaSqlCollector -&gt; DropSchemaSQLCollector<br/> Doctrine\DBAL\Schema\MsSqlSchemaManager -&gt; MsSQLSchemaManager<br/> Doctrine\DBAL\Schema\MySqlSchemaManager -&gt; MySQLSchemaManager<br/> Doctrine\DBAL\Schema\PostgreSqlSchemaManager -&gt; PostgreSQLSchemaManager<br/> Doctrine\DBAL\Schema\SqliteSchemaManager -&gt; SQLiteSchemaManager<br/> Doctrine\DBAL\Tools\Cli -&gt; CLI<br/> Doctrine\DBAL\Tools\Cli\Tasks\RunSqlTask -&gt; RunSQLTask</p> <p>Doctrine\ORM\Mapping\Driver\PhpDriver -&gt; PHPDriver<br/> Doctrine\ORM\Mapping\Driver\XmlDriver -&gt; XMLDriver<br/> Doctrine\ORM\Mapping\Driver\YamlDriver -&gt; YAMLDriver<br/> Doctrine\ORM\Query\Exec\AbstractSqlExecutor -&gt; AbstractSQLExecutor<br/> (Should Doctrine\ORM\Query\Expr\Andx and Orx be AndX and OrX?)<br/> Doctrine\ORM\Query\SqlWalker -&gt; SQLWalker<br/> Doctrine\ORM\Tools\Cli -&gt; CLI<br/> Doctrine\ORM\Tools\Cli\Tasks\RunDqlTask -&gt; RunDQLTask<br/> Doctrine\ORM\Tools\Export\Driver\PhpExporter -&gt; PHPExporter<br/> Doctrine\ORM\Tools\Export\Driver\XmlExporter -&gt; XMLExporter<br/> Doctrine\ORM\Tools\Export\Driver\YamlExporter -&gt; YAMLExporter</p> <p>... I think that's it. More than you expected? I did say: "There is more proper-casing than upper-casing." <img class="emoticon" src="http://www.doctrine-project.org/jira/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/></p> <p>No, not more than I expected. It's mostly SQL and CLI basically. Thanks for the list!</p> <p>We should try to go through that list before beta.</p> <p>Methods should be adjusted accordingly also (even though they're case insensitive). I already started with that. More to come.</p> <p>Most of the Cli =&gt; CLI changes seem to be complete now.</p> <p>Pushing the rest of the name changes towards beta2.</p> <p>More renamings have been done but still more to do. Pushing remaining work to beta3.</p> <p>Final name changes should be done prior to going into RC1.</p> <p>there is much to be done yet, however most of it is also public API class names and might cause quite some BC breaks (i.e. DBAL Platforms and Schema Manager, Mapping Driver Names). I am not sure how to proceed here.</p> <p>Since PHP is mostly case-insensitive on class and method names it shouldn't be much of an issue.</p>