What arguments are there to use a coding style for each distinct language? [duplicate]

Question

I recently had a discussion about our coding style for C# projects. Two things in particular were very hard to agree upon.

1. Method Naming

C# has the de-facto standard of naming (at least public, not sure about private) methods in the PascalCase. Coming from a Java background, our current document states to use camelCase instead.

2. Curly Bracket Placement

Visual Studio by default places every curly bracket in its own line. I don't have a source, but I can think this is also used throughout the industry as a guideline for coding style. Again, due to the Java background, our current policy is to rather write if (...) { (same line).

---

When I raise these issues and non-compliance to (IMHO) standards of the C# industry, I often hear the argument "we won't use different styles for different languages, so every code looks the same".

I think this argument, while it does make sense in some way, is invalid to the discussion. Should you treat every language the same when creating a guide for your code, or use the standards of the industry around that language as a guide instead?

Unfortunately, I don't have any good counter-arguments, besides "it's what everybody else does".

What can I do to push the coding style in the (for me) "right" direction? That is towards what everybody else already does in the industry?

PS: Main languages are Java, C++, C# and JavaScript

Answer 1

I'd say if your Java devs regularly program in C# and vice versa, they might have some argument for making them look the same (slightly easier to read).

But even then, differences can be useful enough to trump reading ease. I for one like to use same-line-open-brackets in JavaScript to remind my brain at all times that the code I'm looking at is not C#.

Otherwise, it's none of their business what the C# devs use.

On the contrary, it's important that the C# devs keep conventions that are easy for interacting with other C# devs, reading and posting C# code online, etc.

Good candidates will be reluctant to work at a place with such a silly mis-application of coding conventions.

Answer 2

There is a case for different styles for each language - it helps you remember that you're writing something different, and thus will help to prevent some subtle errors due to language similarities (ie where you are still thinking Java techniques when writing C# code and vice-versa).

It can slow you down a little when switching, but frankly - this is a good thing. Stopping to context switch is better than diving in and coding without due care.

Personally, I always go with the "whatever style the code is currently written in is the style to use". So occasionally when I work on certain 3rd party code that had used a particular idiom, I maintain that god-awful style.

Answer 3

Unfortunately, I don't think there is any way to achieve your goal. Your workplace has made Java the first-class language and culture, and made C# second-class. Trying to raise this issue will possibly make you an unfavorable person among the coworkers.

That particular coding style may also have the backing of some senior staff in the company. Given that the workplace is already rife with politics, raising this issue alone may be detrimental to one's career.

Also, for a code base that is entirely internal to one company, coding styles that are purely cosmetic in nature can be chosen to go against the industry norm as long as it is consistently applied. (By saying it is cosmetic, it means the style is harmless to code quality). Since consistency is important, the existing coding style will prevail, so your goal will not be achievable.

However, if the company makes heavy use of third-party source code, maintaining the naming consistency in each language will become more difficult. (This difficulty does not affect the curly braces because its effects are not visible on the surface of an API (programming interface).)

If the company's code base does not use third-party source code at all (which could be true for some sufficiently large companies), or if the team decides to write wrappers for every single third-party component so as to normalize the method naming according to the internal standard (which is also a common practice in many companies), then the heavy use of third-party source code will not provide a strong reason for following the industry naming convention.

When all things considered, my inclination is that Ewan's answer is the only one applicable to your situation, and that other persuasions will probably be defeated in a logical debate.

---

All things aside, there is one technicality when JNI is involved. (JNI is used to allow Java code to call into C++ code. Since both languages are mentioned by OP, it is likely that JNI is on the radar when the company's coding standard is drafted.)

JNI requires the C/C++ native method entry points to be named in a particular way. This is enforced by the Java runtime, which will concatenate the Java class name and method name in a prescribed manner, and then look up the JNI entry point. For this reason, it is possible that developers who work on JNI components need to prescribe a naming convention that is to be applied to both the Java methods and the C++ counterparts.