Why using code style is bad for your team
18 Jun 2013First of all let me start saying that I was code style nazi for years. When I started developing software professionally and assembled my first team one of the few things we did first was to set up our code style.
Braces here, spaces, there, tabs vs spaces, and so on. Each developer has it’s own preference. But now I fight with that and preach new thing.
Working on many different projects I noticed how hard it is to set up the dev environment. The longer the list the shittiest the project is ;-)
And usually on the list is “set up your code style this and that”. And try to commit something not matching this style and you’ll be crucified ;-)
For me now it comes to one point - how fast I can set up the environment, start coding and be done with a feature. I don’t want any special set up, hidden steps and other non sense.
I also noticed that teams that have some code style while reviewing the code tend to focus on it, instead of focusing on what the code actually does. Shitty code should be fixed, but code that has braces here or there, come on! You should be able to read that? How else are you going to read code on forums? Or open source?
That’s why I preach now a simpler approach - use defaults, usually company adopts one tool set for the job (like in case of Atlassian it’s IntelliJ IDEA). This way it’s so obvious and easy.
No setup at all is the best set up procedure for me. And whenever you can use this approach (for code style, project structure, etc.) I’m advocating for it.
The best design philosophy is “don’t make me think” and you should embrace it in our projects from the beginning ;-)