I work on a small team, around 10 devs. We have no coding standards at all. There are certain things that have become the norm but some ways of doing things are completely disparate. My big one is indentation. Some use tabs, some use spaces, some use a different number of spaces, which creates a huge problem. I often end up with conflicts when I merge because someone used their IDE to auto format and they use a different character to indent than I do. I don't care which we use I just want us all to use the same one.
Or else I'll open a file and some lines have curly brackets on the same line as the condition while others have them on the next line. Again, I don't mind which one so long as they are all the same.
I've brought up the issue of standards to my direct manager, one on one and in group meetings, and he is not overly concerned about it (there are several others who share the same view as myself). I brought up my specific concern about indentation characters and he thought a better solution would be to, "create some kind of script that could convert all that when we push/pull from the repo." I suspect that he doesn't want to change and this solution seems overly complicated and prone to maintenance issues down the road (also, this addresses only one manifestation of a larger issue).
Have any of you run into a similar situation at work? If so, how did you handle it? What would be some good points to help sell my boss on standards? Would starting a grass roots movement to create coding standards, among those of us who are interested, be a good idea? Am I being too particular, should I just let it go?
Thank you all for your time.
Note: Thanks everyone for the great feedback so far! To be clear, I don't want to dictate One Style To Rule Them All. I'm willing to concede my preferred way of doing something in favor of what suits everyone the best. I want consistency and I want this to be a democracy. I want it to be a group decision that everyone agrees on. True, not everyone will get their way, but I'm hoping that everyone will be mature enough to compromise for the betterment of the group.
Note 2: Some people are getting caught up in the two examples I gave above. I'm more after the heart of the matter. It manifests itself with many examples: naming conventions, huge functions that should be broken up, should something go in a util or service, should something be a constant or injected, should we all use different versions of a dependency or the same, should an interface be used for this case, how should unit tests be set up, what should be unit tested, (Java specific) should we use annotations or external config. I could go on.
Best Answer
A co-worker and I had a similar problem on our team when we first joined (I joined the team first, he joined about a year later). There were no real code standards. We're a MS shop, and even the MS coding standards weren't used. We decided to lead by example. We sat down together and drafted a document that had all of our standards: IDE standards, naming standards, everything we could think of. Then he and I agreed to follow the standard explicitly. I sent an email to the team (from the both of us), and notified them that we had found a lack and we were going to address the lack with our document. We invited critique, ideas, comments, opinions. We received very little in the manner of feedback and only a little push back. He and I immediately started using the standards, and as we brought junior developers onto our projects we introduced them to the standard and they began using it. We have a few leads who were reluctant at first but have slowly begun using the standard for a great many things.
We found that many of the junior developers had recognized the same problem but were waiting for someone else to step up and make the decision. Once there was a plan to follow, many were eager to adopt it. The tough nuts to crack are the ones who refuse to code by any other means, and they'll usually code themselves out of the picture in the long run.
If you want standards, blaze the path. Come up with a suggested list of standards you think would benefit your team. Submit it to peers and leads for feedback. I'm sure other people on your team have similar ideas, but they probably lack the gumption to do anything about it. As Gandhi said, "You must be the change you wish to see in the world."