It’s almost 3 weeks since I’ve started my work for new company. One thing you usually need to go through when you starting you developer’s activities at new place is new coding style, name conventions and other style rules which are different from one company to another. In last 4 years I was working in several project teams and there are always some differences in these side things I was faced to.
Another interesting thing, that in my current company we work in virtual office environment, conception that adds some new advantages, but has some features you should be ready for. In addition to slightly different communication manner, principles of creating project teams and changeable working environment you have some extra portion of mixed programming styles and subjective views on best practices from different developers and team leads.
Involuntarily you start to thinking if there any real way to produce some “common” rules for different teams. My experience says that only way when such thing happens when these rules are strongly dictated by someone. In friendly teams any attempt to do this meets personal preferences of each team member. There are some key points which we use to make some compromise:
-
What are most teams doing already?
-
Which option is the most readable (highly subjective)?
-
Which option will be the easiest to maintain over time?
You can find some reasoning of this stuff here Jason Allor here.
Actually, another possible way to “generate” code style conventions is to commit this work to some tool or development environment. Surely, in this case there should be good reason to “believe” this tool – competent and authoritative source or creators of those rules. In case of C# there some work already done by Microsoft guys like Jason which can be helpful for other teams and project groups. Formerly internal Microsoft tool StyleCop, now announced as “Microsoft Source Analysis for C#” call to possibly be powerful thing to produce well-styled and maintainable code.
