We currently have 3 devs with, some, conflicting styles and I’m looking for a way to bring peace to the kingdom…
The Coders:
Foo 1: Likes to use Func’s & Action’s inside public methods. He uses actions to alias off lengthy method calls and Func’s to perform simple tasks that can be expressed in 1 or 2 lines and will be used frequently through out the code
Pros: The main body of his code is succinct and very readable, often with only one or 2 public methods per class and rarely any private methods.
Cons: The start of methods contain blocks of lambda rich code that other developers don’t enjoy reading; and, on occasion, can contain higher order functions that other dev’s REALLY don’t like reading.
Foo 2: Likes to create a private method for (almost) everything the public method will have to do .
Pros: Public methods remain small and readable (to all developers).
Cons: Private methods are numerous. With private methods that call into other private methods, that call into… etc, etc. Making code hard to navigate.
Foo 3: Likes to create a public class with a, single, public method for every, non-trivial, task that needs performing, then dependency inject them into other objects.
Pros: Easily testable, easy to understand (one object, one responsibility).
Cons: project gets littered by classes, opening multiple class files to understand what code does makes navigation awkward.
It would be great to take the best of all these techniques…
Foo-1 Has really nice, readable (almost dsl-like) code… for the most part, except for all the Action and Func lambda shenanigans bulked together at the start of a method.
Foo-3 Has highly testable and extensible code that just feels a bit “belt-&-braces” for some solutions and has some code-navigation niggles (constantly hitting F12 in VS and opening 5 other .cs files to find out what a single method does).
And Foo-2… Well I’m not sure I like anything about the one-huge .cs file with 2 public methods and 12 private ones, except for the fact it’s easier for juniors to dig into.
I admit I grossly over-simplified the explanations of those coding styles; but if any one knows of any patterns, practices or diplomatic-manoeuvres that can help unite our three developers (without just telling any of them to just “stop it!”) that would be great.
From a feasibility standpoint :
- Foo-1’s style meets with the most resistance due to some developers finding lambda and/or Func’s hard to read.
- Foo-2’s style meets with a less resistance as it’s just so easy to fall into.
- Foo-3’s style requires the most forward thinking and is difficult to enforce when time is short.
Any ideas on some coding styles or conventions that can make this work?
I’d say that before you introduce new rules and conventions, that you should set aside some team time and initiate a respectful and open discussion within your development team about the current codebase. Get your developers to discuss coding styles and the things that they both like and dislike about the codebase and its mixture of coding styles.
In short, get things out in the open; this is more healthy than letting feelings fester, and even if you introduce new rules to fix the code issues, the politics will likely remain.
Let the team feel that they are being treated as sensible adults and that they have some input and influence upon the coding conventions that you introduce.
It’s always worth trying a self-policing approach first, and you may not need to enforce anything, if the discussion goes well.
Most important of all: Try to ensure that everyone listens (including yourself).