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."
I work with a team that grew from 2 developers to 10 in less than a year. I was number 3, and the first to raise a coding standards issue. The two original developers had been working side by side for a few years and they'd adopted a common standard that seemed alien to me. We had exactly the same problems you are describing.
What we did was:
Research coding standards
We spent a few days checking out established open source projects. We knew the team would expand rapidly and we were looking for real solutions based on real projects not some generic guidelines. Also we didn't care for the optimal coding standards, but for a set of rules and guidelines that would make sense and not call for the refactoring of all of our codebase. We were looking for a coding standards hack if you will.
The three of us decided that the best coding standards out there for an established PHP project were those followed by Zend Framework. Fortunately the Zend Framework people provide a very comprehensive coding standards document.
Creating our own coding standards
Of course applying another project's coding standards on our project as is didn't make sense. We use the Zend Framework document as a template:
- First we removed everything that didn't apply to our project
- Then we changed everything that we perceived as a matter of style to our style
- And finally we wrote everything down
So we had a fairly large document at our hands, stored in our fancy wiki, it was a nice read, agreed upon by all of us. And completely useless on its own.
Staying true to our promise
Our codebase at the time was about 1*10^6 sloc. We knew that since we adopted formal coding standards we had to start refactoring our code, but at the time we were pressed with other issues. So we decided to just refactor our very core libraries, a mere 5*10^3 sloc.
We assigned one of us to be the coding standards master (we used local profanity in place of master) with the responsibility of checking and enforcing the standards. We recycle the role every few sprints. I was the first, and it was a lot of work, as I had to monitor almost every commit.
We had several new discussions and small addendums to the original document during my tenure, and finally we had a somewhat stable document. We change it every now and then but most of these changes are on new features of the language, as PHP 5.3 was a major release in all but name.
Dealing with the new guy
When the next new guy arrived, it was time to put our coding standards to the test. After a small introduction to our codebase, we asked him to evaluate our coding standards document. He almost cried. It appeared that he did everything differently.
As I was the coding standards master at the time, it was up to me to evaluate his input and revise the document accordingly. His proposals were:
- Matters of personal style (summarily dismissed)
- Standards that made sense to his Java background but no so much with PHP (dismissed)
- Conventions that he carried from his brief exposure with PHP (some were dismissed, but a lot proved to be popular conventions that we never thought of or found out in our initial research)
For the next couple of weeks he was assigned a simple task: Bring several parts of our codebase up to date with the standards. I had to carefully choose those parts based on a few rules:
- Code should be relatively easy for someone unfamiliar with our codebase (and PHP in general)
- Code should be on what he was hired to do
I monitored his process and he did a fine job. We identified several parts of code that was impossible to fit our document and revised accordingly (code and / or standards, whichever made more sense)
And then another new guy arrived. We repeated the process (different master this time), and it worked again. And again.
In conclusion
- Create a coding standards document, but make sure that your standards are not exclusively your own but do reflect common standards in the wider community of your platform.
- Assign a similar role to our coding standards master. Someone to monitor at least new code, and especially new code from new members. Recycle the role, as it's extremely boring.
- Always evaluate input from a new member. Always revise your standards if it makes sense. Your coding standards document should be evolving, but slowly. You don't want to re-refactor your codebase at each iteration.
- Allow for some time for each new member to learn and adapt to your standards and conventions. Learn by doing works best in these situations.
- Wiki works wonders for such documents.
- Code reviews work wonders for any situation!
At some point in the process it was suggested that we use a pre-commit hook to automate checking of the standards. We decided against it for a variety of reasons, there are some interesting discussions on StackOverflow on the issue:
Some are PHP specific, but the answers apply to all platforms.
Best Answer
There is such an organization: Sun/Oracle itself. The document is called Code Conventions for the Java Programming Language, and it describes most of the conventions you need. Just have everyone agree to read it and follow its recommendations.