The coder Mihai has switched back and forth between C# and Java a few times now. Whenever switching, you notice how your brain gets used to the conventions used hitherto… I just recently began work on yet another Java project and was being pounded with IDEA’s error highlights on the (lowercase) “string” variables. You get my drill.
As far as the aforementioned languages, here are a few major distinctions in terms of code style and naming conventions in the two languages:
Method capitalization - method names in Java are camelCase, whereas in C# they are PascalCase.
Namespace naming - packages in Java begin with the TLD followed by the company name, usually similar to the website (com.mycompany.myproduct); in C#, a similar convention exists, although without the initial TLD component (MyCompany.MyProduct).
Prefixes - Java promotes no prefixing of any kind; C# luckily ruled out against Simonyi’s hungarian notation, or against the C prefix on class names sometimes seen in C++ libraries, but has voted for an I prefix on all interface names.
While most of us will not need to worry about this transition, there are a few cases in which you’ll find yourself in this situation. You may be be asked to port code from one language to another. What, then to do about the guidelines? They’re just guidelines, right? It’s not like they are formally enforced, so who cares?
Actually, it’s not quite like this. If you’re a religious follower of the code style and naming conventions, then you MUST follow the guidelines of the language at hand, even for those second-hand temporary bastards that you use only on occasion. Style leaks create inconsistencies and defeat the purpose of a naming convention. Enforcing a foreign convention on code is no better than not enforcing a convention at all.
A few years back, I wrote a utility in .NET; a Java aficionado was my direct supervisor. Of course I was consistent in following the guidelines and, since the tool was owned by my company, I naturally prefixed all my namespaces with MyCompany.MyToolName. Guess what? The guy had me change it to Com.MyCompany.MyToolName. Though he probably felt entitled to project Java conventions onto C#, he failed to see that, beyond his selfish universe, the future audience of the tool is acquainted to slightly different naming conventions, conventions that sink into the subconscious and trigger subtle associations.
More recently — just the other day — I skimmed through a Java XBRL library and found C++ and C# style code — not just C#, but both. It began with the I prefix on all the interfaces and ended with m_ and s_ prefixes on all class fields.
Required reading: Java code conventions; C# naming conventions.
Post a Comment