We're a small/medium sized company with a dozen or so software developers, developing our own in-house software for in-house use. Given that there's so few of us and there's just so much work to be done, for most part each developer handles a separate part of the system and doesn't share their work much with other developers. Each has their "domain" so to say.
Occasionally however the domains overlap and we need to collaborate; and also the arrangement means that it's hard to replace people and when something goes wrong we must be there to fix things because nobody else can do it (at least not quickly). So this arrangement is both nice (we each have full creative control) and not nice (we're basically forced to be on call 24/7, although in practice it's a bit more relaxed than that).
Recently we tried a little "workshop" among ourselves to promote some better coding standards, namely, unit tests. (Yup, we're one of the people not doing those yet…) During the 2h meeting we aimed to create a small sample program with unit tests, just to get a feel for doing it.
It was a fun 2 hours, and we did manage to produce a little bit of code in the end, however an interesting issue became painfully obvious: having lived so much in isolation for so long, each of us has basically our own coding style.
Now, I'm not talking about tabs vs spaces, camel case vs snake case or some such other cosmetic difference. I'm talking about principles of arranging code. How to name things. What folders and namespaces to place them in. Do I split this code into 3 classes or just one? 5 tiny files or 1 gigantic one? Abstract it away with interfaces and factories, or call it directly? Getters and setters or naked fields? Etc.
At times, writing the absolutely trivial program nearly devolved into a shouting match, although we were thankfully able to retain our cool in the end and no feelings got hurt.
So this got me wondering – how do you normalize coding style among multiple seasoned developers with each their own strong preferences? The different styles certainly are bothersome when we do need to interact with each other's codes, not to mention confusing for any newcomers. And when some piece of code gets handed from one person's domain to another's, there's always the strong desire to rewrite it to match your own ways.
First of all, are there any rules for how to lay out your code? Any standards? So far I've only seen the cosmetic stuff about spaces and cases. Basically how to format your code once it's written (in your head at least). But are there any guides about how to write your code, how to arrange it and how to name it? Where and how to split it in pieces and how to make the pieces interact?
If there isn't a standard and we need to create our own, how do you go about doing that when everyone has a strong opinion of what is right and what is wrong? Now, mind you, we're all seasoned developers here; we realize that none of our approaches is inherently better or worse than any other – just that each one of them has certain strengths and certain weaknesses. But we also have a strong opinion about which strengths and which weaknesses matter the most. So how do you decide on The Right Way™ and how do you make sure everyone sticks to it without hurting any feelings (too much)?
One way I've heard of is to select a Glorious Leader who then forces his preferred style onto others (via code reviews and meetings and whatever), but… you need a really good Glorious Leader who is indeed head and shoulders above others. What if you don't have one, and we're really all equals here?
Best Answer