9

First a bit of background: My current development manager is taking another opportunity the end of this week, leaving our team with four fulltime developers, a part-time intern and a web designer (who is technically part of Marketing, not AppDev). At this time we aren't promoting or hiring a new manager.

The previous manager never would take the time to come up with a set of coding standards to adhere to (to put this in perspective: My one-year anniversary at this job is in two weeks and I've been talking to him about standards since I started). Due to this, all of us four developers write code our own way: Some of us follow the Microsoft naming conventions for .NET, some use Hungarian notation, some use a mix (e.g. mixing PascalCase and camelCase for parameter names), and it's entirely random when you open a code file what standard it will follow - about the only thing consistent is that braces are on separate lines.

Two out of my three co-workers have approached me to create a standard coding document that we can use and enforce moving forward (although I am technically not the most senior developer, the fourth developer having been here for several years, two co-workers and the intern look to me for advice/guidance but we do not have a team lead). I have been meaning to do this for a while but the now-departing manager would always put it on the backburner; his departure now gives us a chance to take some time and configure things correctly to facilitate a proper software environment and not the rushed hodgepodge we currently have.

How should I go about doing this and introducing this standard to my team without causing friction? I don't want to make it look like I'm "taking over", although were I offered the manager position I would accept it. As I said two out of three other developers are on board with me creating one, but the fourth (the true "senior" in length of time) may or may not accept it. I plan to start with the .Net conventions from Microsoft (e.g. do not use Hungarian Notation), add some personal preference (e.g. _camelcase for fields) and specifically call out certain strange practices we use here as not to be used (e.g. naming a class with an underscore at the start), but what else should I include? I don't want to get into architectural guidelines as that will cause friction and we have a very large, and smelly, existing codebase that wouldn't adhere to it, and we're nowhere near at the point of coming up with a refactoring strategy.

To summarize: Beyond basic naming conventions what, if anything, should I include in a coding standards document (examples would be great - I haven't managed to find any concrete examples of what such a document should look like), and how should I present it to my team without sounding like the new dictator.

Improve this question
5
  • In addition to naming conventions, you'll want a standard way of describing what the file does in the headers, plus possibly a standardized directory structure. See Google's style guide as an example.
    – chrisaycock
    Commented Dec 19, 2011 at 20:43
  • You have no manager/team leader and your worried about coding standards!
    – mattnz
    Commented Dec 19, 2011 at 21:04
  • We may not need a team leader to be honest, most of us agree on things and collaborate on our own. The standards are a concern because it's been "let's talk about them" for nearly a year now with zero time being allocated to sitting down to discuss some.
    – Wayne Molina
    Commented Dec 19, 2011 at 21:07
  • 2
    The fact you have not sat down for a 30 minute meeting in nearly a year indicates to me you are indeed needing a team leader.
    – mattnz
    Commented Dec 19, 2011 at 23:21
  • Perhaps. The previous manager was in a hurry to crank code out, not "waste time" with things like talking about standards or try to implement CI, tests, code reviews, or the like. The one time we tried to hash it out, the senior developer got uptight that the meeting was taking too long ("I have work to do!" was the exact quote) and stormed out, ending it abruptly.
    – Wayne Molina
    Commented Dec 20, 2011 at 13:34

8 Answers 8

Reset to default
10

How should I go about doing this and introducing this standard to my team without causing friction?

You also say:

Two out of my three co-workers have approached me to create a standard coding document that we can use and enforce moving forward

Looks like you already have some buy-in from most of the team. Make creation of the document something that is done by all of you (all four if possible). If this is too time consuming, come up with your document and show it as a draft to your colleagues. Once all of you have agreed and finalized a version you are good to go.

A good place to start is a look at the different stylecop rules - you don't have to adhere to them all, but these will give you an idea of what your document should contain. As an added bonus, you can easily implement stylecop in your solutions and even integrate into an automated build (failing the build if there are violations).

To summarize:

Look at existing tools and standards to decide what you want in yours.

In order to avoid looking like a dictator, make the change a collaborative one.

Improve this answer
1
  • "In order to avoid looking like a dictator, make the change a collaborative one." So true. You have three routes to success here: 1. use an outside standard, that way everyone has something they like and something they don't (fxcop, stylecop, or even any .pdf you can find on the web). 2. Collaborative generation. 3. You are a legendary hero with years of experience and people flock to work with you and are loved by all, or maybe your last name is Zuckerberg, Page, or Brin.
    – anon
    Commented Dec 21, 2011 at 2:22
7

Beyond basic naming conventions what, if anything, should I include in a coding standards document

Nothing.

Take your time. Go slow. Don't waste time writing. Coding conventions only work when they're part of the common culture.

If they're not part of the culture, they're simply ignored.

How should I go about doing this and introducing this standard to my team

Code reviews. It's a great place to introduce the problem that's solved by coding conventions.

Most of the time, conventions are simply a waste of time. When you have an actual problem (i.e., unreadable programs) that you can solve through coding conventions, you can get to 100% compliance quickly.

Coding conventions which are merely personal preference don't solve a problem. And indeed, during a code review, you may find out something better and actually change your personal preference.

Don't canonize too much in a coding conventions document. Work cooperatively to arrive at a common understanding.

I don't want to get into architectural guidelines as that will cause friction and we have a very large, and smelly, existing codebase that wouldn't adhere to it,

Bad policy.

An architectural standard is never something with 100% adherence. It can't be. It's always a "forward-looking" description, toward which development evolves.

Every good architectural idea will lead to a new architectural direction. And that's what innovation looks like -- a path, not a goal.

and we're nowhere near at the point of coming up with a refactoring strategy.

Good. Don't develop one. By that I mean "don't stifle innovation by writing down too many things which may or may not be best possible approach."

Improve this answer
4

With something like coding conventions, I would say that any specific convention should be 100% unanimous or find some middle ground that makes it 100% unanimous.

  • Set a deadline for the document to be completed, this will force others to take it seriously.

  • Do the work of compiling the document, nobody will feel like helping you but if you own the work then nobody will fight you on it.

  • Send out proposals for various coding conventions based on different styles that exist in the codebase now. Gather feedback, and set up a meeting where they can be voted on.

  • Nobody leaves the meeting until each convention has come to 100% unanimous agreement

  • New people to the team will have to abide by the document and will have no say. It is like the Constitution at that point.

Oh and no Hungarian notation. Seriously, I would rather papercut my eyes than have to look at code in Hungarian notation.

Improve this answer
2
  • 1
    The Hungarian is a big thing, and so is the underscore class names. Seeing something like _Customer oCust = new _Customer(); makes me shake my head in bewilderment.
    – Wayne Molina
    Commented Dec 19, 2011 at 20:48
  • I took on the task of compiling a new set of Coding Standards for my company. Fortunately, I had help from a set of Senior Developers who were also new to the company and we had a VP backing us up with enforcement. We update the document every few months as needed. After the 2nd big revision, I added section numbering to the document which made it easier to reference a particular standard when a project failed code review. "Check out section 5.3.4.6 on using functionA instead of functionB". Over the last year, we're finally getting fewer failed code reviews.
    – Adrian J. Moreno
    Commented Dec 19, 2011 at 22:50
1

Coding standards are going to be a challenge to get accepted. Some people like to code in their sandbox and just do their thing despite the fact it can cause issues if it breaks and others are trying to fix it.

If you're using Visual Studio with .NET take a look at StyleCop. You can use the pre-defined rulesets or write your own. Then get everyone to agree before code reviews (if you have them) that you should adhere to the settings.

Improve this answer
1

From a technical viewpoint:

Point out the inconsistencies that are really a problem for the team and define coding rules for solving these problems.

From a relational viewpoint:

If you want to get the senior involved, get some inspiration from his own coding conventions.

Improve this answer
4
  • Heh well part of the reason we want coding standards is because the senior doesn't follow any. He uses Hungarian notation everywhere, he doesn't know that methods can be overloaded (so there will be like a GetFoo method, and then GetFoo_WithSomethingElse method that has the same thing but with one extra parameter, with all the logic copy-pasted and then the extra bits added) and he doesn't understand class design other than just stuffing lots of logic in a code-behind file. The departing manager didn't care about doing things different so just went along with that style.
    – Wayne Molina
    Commented Dec 20, 2011 at 12:27
  • This is what I thought. It looks like your project has non technical issues and that you try to solve them with a technical answer.
    – mouviciel
    Commented Dec 20, 2011 at 12:48
  • What would be the correct way to solve the issues then? The issue is nobody has given these things any modicum of thought since the company started.
    – Wayne Molina
    Commented Dec 20, 2011 at 12:58
  • I may be wrong, but the problem I see is that a senior developer who had written code for many years has no reason to change, in particular if the request comes from a junior (I don't question your competency). I see no general solution, as I don't know enough about the situation.
    – mouviciel
    Commented Dec 20, 2011 at 13:53
0

As long as you are not the new manager of your team, you need consensus about having a coding standard at all (and if you were the manager, you should really try hard to get consensus in the team before make such a decision "from above"). And it may sound simple, but only talking - especially talking with the fourth developer - can solve this.

Improve this answer
0

Do you have a company Wiki? Or, failing that, a server that you can drop one on?

If so then just create a page. Call it a living document. Put down a few non-contentious standards and encourage everyone else to collaborate. Keep adding items every few weeks, encourage discussion but in a way that says "if no one disagrees then we should expect this to be followed." If you can, convince everyone to subscribe to the standards documents, so you can see any changes your colleagues make.

Also try to get the team to begin code-reviews. Every job goes through two developers. This will encourage discussion and standards enforcement, and make it so that everyone is equal, not one developer dictating the rules.

Edit in response to comment:

You can sell code-reviews as a way for Dev #4 to spread his wisdom. Even when his code is being reviewed, it is an opportunity for people to see his magical code and bask in awe at it. Really, it is a way of promoting discussion. Where the coder and reviewer can't agree, it should go to the team. Where the team can't agree, research should be done.

Speaking of research, do some on code reviews. No one whose opinion counts for much thinks they're a bad idea. Put it to the team, including the CIO, in an email with lots of links. It's hard to argue against them without looking like an obstructive idiot.

Here are a few to get you started:

As for a Wiki, I really would recommend taking the time to set one up (Wikis give the illusion of collaboration, even when it isn't really there). But if you can't then a Word document on a shared drive will do the job.

Improve this answer
3
  • We don't have one; it's something we (whenever I say "we" I mean myself and the two devs that defer to me - the fourth is essentially a "special operative" and handles the legacy/complex parts of the app that the rest of us don't touch - even before the manager left Dev #4 reported directly to the CIO, not to the manager) were talking about. Code Reviews I'm not sure if we can do, as some might take offense if their code is questioned (more than likely Dev #4 as he is going to have to change how he does things to adhere to the new standards anyways)
    – Wayne Molina
    Commented Dec 19, 2011 at 20:55
  • @WayneM Where I work, we didn't have a wiki either. It was easy to set up a dokuwiki vm to get started. You can run the thing off your personal box if necessary, and once things get going, it's pretty easy to migrate to a "real" server.
    – Spencer Rathbun
    Commented Dec 19, 2011 at 21:10
  • 1
    @WayneM: See edit.
    – pdr
    Commented Dec 19, 2011 at 21:13
0

Comment and whitespace standards are good, along with tools to migrate between different styles. I use tabs in my python code, which is considered bad style. However, a simple VIM function converts between the two as necessary.

Also, think about code comprehension levels. The purpose of a style is to communicate information to the programmer reading the code. If you can understand reduce(lambda x, y: x+y, map(lambda x: x + 1, theList)), but your co-workers would rather see:

for pos,item in enumerate(theList):
    theList[pos] = item + 1
tmp = 0
for item in theList:
    tmp = tmp + item

Then this is important to hash out. Same with white space. You need to figure out what level of code compression everyone is comfortable with.

Finally, how do new projects, and current projects, get cut up? One class per file, utility functions follow a naming scheme, no global variables or scope leakage, random project files are orthogonal and loosely coupled, and so on. This provides an important understanding base for everyone. It doesn't matter what the coding standard is, if every project is so intertwined that I have to go through the whole code base and really grok the project before I twiddle foo().

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.