Thread by @jaredpar

Wanted to share the steps I use when attempting to establish a coding style in a software project. Seen a number of people struggle with this over the years and wanted to share a strategy I've had some success with.

First gain consensus on the idea, **not** the implementation. Get developers to agree that a single style would be desirable. Push on ideas like it helps reduce friction on PRs, makes code more portable within your code base, easier for new developers to learn, etc ..

Nominate and choose a "decider". There will be conflict over style choices. Team needs to pick a member to make the final decision on style before the various styles are discussed. This helps the team pick someone who's decisions they respect, not because they share the same view

It's critical this occurs before style specifics are discussed. Choosing a decider after means the team likely knows their style preference. This makes choosing the decider feel like you're choosing the style. That ups the stakes significantly.

Developers who's nominee doesn't win will possibly feel like they've already "lost" the debate too. That can lead to them not feeling invested in the rest of the process and mentally checking out. In bad situations this can lead to them also not respecting the outcome. Avoid!!!

Next set a meeting, max one hour, to decide how the style will be enforced: editor config, CI gates, resharper, etc ... Make sure to consider the differences between developer and CI experience. Basically figure out the mechanics and developer experience.

Every proposed system gets a developer to act as a champion to present its virtues. Give every champion same fixed time slot to present their ideas. Avoid making a decision in the meeting (unless there is consensus). Decider decides after and record it via email to the team.

7+ tweets in and I haven't mentioned actually choosing the style yet. That's deliberate. Talking about specifics of style should be done as late as possible. Get the team invested in the process and outcome before you introduce the elements that are most likely to cause conflict

Now comes the fun: choosing the style. Have everyone who is passionate submit a style proposal for consideration. This should be done in two pages.

First page is describing the style to the team. These are the rules to follow. Set hard limit of one page here. Anything longer is likely going too far into details / be over prescriptive. Want general conformity, not make developers feel like style is a burden

Second page is justification. Ban the words I, me or my. The justification should not be about personal beliefs but why this would be beneficial to the team.

Good arguments here tend to be along the lines of:
- This is how the general community decided
- This other team, who we work closely with, picked this hence it will help us work together
- 90% of our code is already this way so we're just picking our defacto style
- etc ...

Have another meeting (maybe two hours this time). Give each proposal champion the same time and let them present. Leave the meeting **without** making a decision. Having time between presentation and decision gives everyone time to reflect and consider (not just the decider)

Decider holds another meeting to present the decision and elaborate on their thought process.

Lastly though is the most important step ... move on. Style is a silly thing to get upset about. Once the team has decided go out and do something fun together: have lunch, get coffee, go bowling, etc ... :)