How to make developers follow coding standards?

Question

How can I make developers follow coding standards?

In our company:

1. I've given documents and they don't have the patience to read it and follow it.
2. I've tried telling them again and again "please do it this way" they nod their heads, but still do it the wrong way
3. We're doing a project for the third time and still they don't seem to follow it properly.

I'm now so tired of this. What is the best way to set standards for coding and make sure they follow them?

Edit:

There are just about 10 developers in my team. They're over pressurized and do not take the time to put comments and do the code neatly since there's more pressure to complete the product from our management. What would be the solution for this?

Answer 1

You have the standards. You have a process for them to follow. If they do not follow, terminate them and find qualified individuals who can follow standards.

More specifically,

1. At the beginning of the project, review the standards with the team. Communicate that they must be followed.
2. At the end of the project, review to ensure they were followed. If they were not, work with the individuals responsible for not following. Ask questions regarding why etc.
3. Give him/her a second chance.
4. If repeated, terminate the individual.

Answer 2

Automate it.

You could integrate StyleCop and FxCop (Code Analysis in VS2008) into your build process.

Thus, when someone checks something in which breaks the rules, the build will break and they'll have to fix it. If you don't have an automatic build process which supports this, you could always run the tools manually prior to code reviews etc.

You probably won't find a perfect match for your coding standards, but you should be able to get something pretty close.

StyleCop

http://code.msdn.microsoft.com/sourceanalysis

FxCop:

http://blogs.msdn.com/fxcop/

Answer 3

It sounds like you aren't respected enough.

Do code reviews, and discuss the coding standards with the team. Maybe they don't adhere because they don't agree. Be flexible.

Perhaps if you're doing a project for the third time, it's YOU that's doing things wrong.

Answer 4

Technical Solution if you're using Team System you could use checkin policies to enforce it. Other versioning systems no doubt support similar things. You'll need the TFS Server Power tools for this.

Non-technical Aside from a technical solution you might want to explain the reasons you're requireing these coding standards (quality, legal etc.). They might feel the policy is overly restrictive or simply do not understand the necessity. If you can convince them of the need to do this, you no longer will have to force them.

Answer 5

Go get more obedient devs.

On a serious note: I can say for myself that I tend to ignore (or reluctant to follow) practices I find downright unreasonable, too authoritarian or plain stupid. Try speaking to your guys and ask them what they don't like about the doc.

Answer 6

I agree with Joe. Automate as much of it as possible as part of a continuous integration process. The easier is to comply without losing focus from the task at hand (programming), the more people will comply.

Answer 7

Have you tried a wooden ruler across the knuckles? Worked for me in school :P

Seriously though, standards are there to be followed, if they're not being followed and you're in a position to follow through with training and disciplinary action, then follow disciplinary procedures. If you're not, and you can't convince your higher ups that this should be followed then it seems you have two options:

• Suck it up and make the best of it
• Start looking for another job

Answer 8

Use an intelligent code formatter and probably an analysis tool to check if the standards are followed.

Use some sessions to introduce the standards.

Introduce a kind of an award for the programmer with the best compliance for the standard each month.

And if all fails, get rid of them.

Answer 9

In my experience, people do not follow the standards be cause they don't know them or do not care about it. Sometimes, coding standards are poorly communicated, even if they are new and considered to be important.

This kind of problems should be solved by

• Training
• Communication
• Reviews

If people do not listen, the team leader should care about it and help forcing the guidelines to be taken serious.

Answer 10

If you have seniority over them, then do a code review and fail them for not adhering to the coding standard. If it continues you can give them a formal warning. If it then continues you can fire them and get people in that can spend 20 minutes reading a coding standards document once in their lives.

I don't know what IDE you use, but Eclipse lets you set up code formatters that you can distribute around your developers, so this might also be an idea.

However there may be an underlying problem - that the other developers dislike your coding standard. It might be best to first find out if this is the case. If your coding standard is actually not a common standard in your language then they might just be passive aggressive as long as they can get away with it. Maybe you should involve them in the development of a coding standard that they are all happy with, mostly.

Answer 11

Are they incompetent, lazy or ignorant?

My experience with this kind of thing is that it starts with leadership, and precedence. Precedence, meaning that people figure out where the line is drawn, and they hang out there. One example I can think of was a new programmer coming on to a job that had been filled by the same guy for 12 years. The code that he had to maintain was a sloppy mess. So he knew he could get away with murder...since the last guy left on his own accord, never getting fired after 12 years of blazing incompetence.

If you've already drawn the line too far out, reign it in. Fire one of em explicitly for not following standards.

It sounds like you've tried to cure the ignorant, leaving you only with the lazy and incompetent...neither of which are worth curing. I'd cull the herd if I were you. If that doesn't work, look for a job outside of management.

EDIT: In response to your "pressurized" addition, the project manager should do their best to absorb as much of that pressure as possible. The best managers know what their team is capable of, and know how to tell management this. You need to be the liaison between team and management, and if management is rushing things along, you should make it clear to them that quality will suffer. If the people with money don't care as much about quality as they do about getting it done...well, you can't be picky about standards. If they want quality, they will listen to a confident manager who tells them that his programmers cannot create a quality, maintainable application without standards enforcement.

If them feeling pressure is what is doing it though, then you need to work on absorbing more of that pressure yourself and not letting it get to your team. That is a big part of being a project manager.

Answer 12

Were the developers consulted when the standards were written? I hate having to follow guidelines that someone came up with out of the blue and did not consult some of the devs. It happens all the time.

The other thing that bugs me is someone giving me guide lines to follow that does not actually work on production code. There is a big difference in the theoretical right way to do something and the practical right way to do something.

Answer 13

Take a meeting to discuss pros and cons of the points related to implementation of coding standard. Take different opinion from every peer and filter out all suggestion.

Convey the importance of following standards and their benefit to understand them completely.

Make them as a habit.

Answer 14

Just get rid of them and find new ones. If they're too lazy to do things right, they don't deserve to be employed. In this economy, you'll have 100 resumes in your hand by morning.

Answer 15

In a civil manner, approach them (the other developers) with a prepared document or thoroughly thought through dialog about the pros of adopting a set of coding standards. Identify the pitfalls with the approach they take currently and provide them with sample scenarios where their current methodology could negatively affect the end product.

If you feel strongly that a set of standards will prove beneficial, go above their heads. In the same manner as before, approach a higher-up with a drafted set of standards that you believe could improve your teams software development. Identify the benefits, provide sample scenarios, and sell your idea.

However, always be mindful that you do not want to alienate your fellow programmers or project yourself to them in a negative light. You do not want to create friction between yourself and the other developers; it will negatively impact the team and the company. The other developers may feel that your trying to push your personal method of programming onto them.

Whatever you may do, I'd recommend you approach the situation delicately. Make sure you think your approach through before implementing ...

Answer 16

I agree w/ Anton. You need their buy-in, else the coding standards are just arbitrary rules meant to inconvenience them (at best) or stifle their creativity (at worst).

I also recommend making the coding standards concise, and, for the most part, tell your devs what they shouldn't do rather than providing an exhaustive list of what they should do. Find stuff that they'd reasonably agree on (like "avoid using empty catch blocks like the plague, as they just mask errors"). Make it known that they are the beneficiaries of the dev standards to achieve buy-in from the majority.

Rushing to fire non-pliable employees isn't the answer. Turn this into a positive experience for your devs and everyone wins.

Answer 17

Automation is probably the best answer to the problem, the aforementioned fxcop or team system solutions work well.

There might be another issue at work here, I know when I was a junior dev I was handed a huge coding standards doc and asked to build everything to match that. I remember being overwhelmed with the sheer number of items, I plain couldn't remember to do it all, particularly when trying to get something working to a deadline..

If your standards are verbose it might be worth picking out the items you'd most like to see fixed and focus on those, then phase in the others gradually, it might work better than expecting them to change all their bad habits at once.

Answer 18

Edit: There are just about 10 developers in my team. They're over pressurized and do not take the time to put comments and do the code neatly since there's more pressure to complete the product from our management.What would be the solution for this?

In my experience, it takes a very strong individual to "train" upper management on how software development actually works and to stand up to them. It's obvious that you're very frustrated with your situation, but unfortunately it might be impossible to fix. You probably won't get the resources or the cooperation that you need. I've worked in that type of environment and my solution was to find another job.

Answer 19

Maybe your standards are too restrictive, Coding standards are good but sometimes more is less. Give them a one page summary as to how their code should look, Do code reviews and fail the ones that don't adhere to the standard. I also like the suggestion of automation.

Explain to them why coding standarads are a good thing.

I use Code Style enforcer in Visual studio and eclipse enforces coding standards.

http://joel.fjorden.se/static.php?page=CodeStyleEnforcer

Answer 20

Talk, talk, talk to them, i think if you know that is a good programmer you cant loose him/she. Is not easy to chance the way that your write code, is ease to forget the new standard when you are more worry about to write down your idea.

Answer 21

Each developer has his own programming style, based on his experience with various languages or in various working environments. Each person develops his/her own style based on many factors. You cannot MAKE someone follow strict guidelines for coding.

One possible solution, albeit with limited rate of success, would be to gather them and discuss the requirements, take feedback from them on their own style and try to find a compromise between these. Try submitting this compromise to your superiors or to those that compile the coding standards for your company.

Also, the developers should be told about the importance of coding standardization, without pressuring them into adopting your standard and into reading whole pages about how they should write their code. Communication is the best way to get a problem solved and a solution on the table. Without communication there is only chaos.

As has been suggested, you can also try a code style formatter prior to revision.

Answer 22

You ought to instate code reviews where the senior developers review the code of the other developers. If they don't follow convention, they fail the code review and it won't make it into the repository.

This requires a bit of human-engineering in that it is more process-based than software-based.

Oh, and tight deadlines are no excuse for bad code. As programmers it's our job to write solid quality code that is maintainable by the rest of the team.

Answer 23

When looking at the questions you asked at SO, I'd say you are having an acceptance problem with your developers. You are not seen as someone who should tell senior developers how to do their work.

So focus on what is needed, instead of how. They should be able to understand that it is important to have coding standards. But it should be their standards, not yours. Ask them to make up their mind, make sure they get enough time to talk about them and make decisions and then write down their decisions. Then you can do something when they do not follow the standard.

[edit] Replace or educate the management. Management doesn't care, so why should they.

Answer 24

It doesn't sound like you are their manager. If not, the first thing you need to do is get management buy-in. Have your development manager integrate the developer's adherence to standards into their employee reviews. You should have enough data points to sell the concept to your boss...the benefits of coding standards are well documented on the web.

Secondly, it's important that the developers themselves have some sort of input into the coding standards. Otherwise, it feels like you're dictating standards out of a vacuum. If the developers have some say into what makes it into the company's coding guidelines, they're more apt to follow it.

Finally, the use of automated tools as mentioned in previous answers will make it code reviews less painful because you can expect, at least, a minimum of compliance.

Answer 25

Coding guidelines are important, but be careful not to:

• be too pedantic. Easy to follow/easy to remember rules are good. Public (eg: to your customers) interface standards are good. Imposing if an internal variable must be called num_of_elements or number_of_elements or nelem is too much.
• stepping from standardization into their creativity. For example, deciding that Singletons are forbidden is too much. Being a programmer is not more different than being an artist. You have to leave some degree of creativity.

In addition:

• Do peer review. When a developer commits some code, another developer must review it and approve it, also in terms of coding standards. If a fault is found, you don't put blame on a single person, which is never good, but you split the chance of the error to happen to be simultaneously on two (willing or unwilling) developers.
• If you are a manager, do find the time to perform this review as well, even code with them. A good manager is part of the team, and shares its tasks and its burden. If you are just a "mail, documents and orders" kind of manager, you will not get respect from your team, in particular if made of enthusiasts, as opposed to mindless typing monkeys. Be as you are a more experienced team member, get your hands dirty together with them.

Answer 26

While I agree wholeheartedly with automating your standards, I'm really curious as to what your company's standards are and how many people here would do exactly the same thing your developers are doing.

I've worked with people who have typed up full documents of what they considered to be standards and tried to pass them off to their colleagues. Here's where they failed:

1. They created them in a bubble. The team(s) weren't consulted.
2. They were based on a language we didn't use.
3. Most rules had a foundation that most considered a flaw. "If you have a big method/class" was a justification for variable prefixes; why not just have small methods/classes and not worry about what you're naming things?
4. The commenting methodology was based on their academic rules. Overly verbose function headers, etc.
5. They were focused on the wrong things. These were primarily focused on the naming of variables, methods, and classes so they would follow a certain form (certain prefixes) instead of content -- "do they accurately state what they are/do?" is the only question that matters with naming (except in languages where it does...).
6. They just didn't have the clout for people to care.

Your best bet is to get a weekly code review meeting going where you put your code that follows the standards up on the screen and get your colleagues' critiques. You'll see where your standards fail and you get "good" code in front of them. Seeing good practices in action should influence future decisions.

Just be prepared to be humbled -- the problem could be you.

Answer 27

It's hard to teoubleshoot something like this without more information, but in my experience I've seen people stray from established code standards for a number of reasons.

Here are some common causes:

• Deadlines keep changing causing technical debt (shifting goal posts),
• 'Just get it done' mentality (usually driven by management)
• Lack of peer review
• Lack of responsibility
• Disagreement about the coding standards or standards are too granular/restrictive
• Standards not clear enough or not properly understood

Your first step should be to try and understand why people aren't following the standards, before you figure out ways to enforce it - if this is the third project obviously something is wrong which isn't going to be easily solved.

At the end of the day you need to be able to justify the cost (time/effort) of enforcing a standard - i.e. if the standard is very granular, it's more expensive then more relaxed standards.

Secondly, if you want people to take them seriously, you need to have some clout within your company to enforce the standard. You may need to make an example of someone who doesn't follow the agreed standard (see below).

Lastly, you really need to seek input from the development team whether you believe they are experienced enough or not. If anything, you really need to be able to justify the coding standard by saying you've given everyone an opportunity to provide feedback and input into it - i.e. it's an agreed standard.

Answer 28

Simply telling them to do it, saying that your way is the right way is guaranteed to fail. Pretty much 100% guarantee that it will fail. I have seen no exceptions. (you can quote as many books and websites and experts on the subject, the outcome is the same)

Depending on the age of the company the momentum of the engineers is what made that company what it is, so if they are following the momentum they are the ones doing it the right way.

If you want to succeed

1) you must have significant buy in, which means the group has to work on the solution and not be dictated to

2) big changes will fail, if the company has been around long enough you have to work on polishing, not starting over. Make small tweaks, one or two tweaks only at first. If you succeed then you can try for another, if you fail then give up...when in rome...

If it is bothering you this much then perhaps you are either in the wrong job or in the right job at the wrong company.

Standards, process, etc are generally as touchy as abortion and religion, the more you push the more they dig in and the less likely you are to make any progress.

Using or quoting fads like tqm, cmm, 5s, iso, six sigma, etc are a recipe for failure. Now being a contractor going from company to company TEACHING those fads, that will make you wealthy, perhaps you should look into that.

There is no I in team if you are doing this without the team then you are going to fail. Getting management buy in but not the teams buy in results in mutiny then failure or layoffs and failure or walkouts and failure, losing your key staff members and failure. You have to join them not fight them, at this point you have to undo the fights you have already had, it will be an up hill battle.

Answer 29

I would start by rephrasing your question: "How can I convince developers that following coding standards will make their lives better?"

There are at least two parts to the answer:

1. The burden of proof is on you as the advocate: if you can't make the business case for why adopting the standards will make life better in measurable ways, your coding standards are not worth adopting. This is your major stumbling block: you already have an organization where people are employed to do work so the business clearly already has some success. How does your standard make things better? Your answer should be phrased in terms of dollars or hours of people's lives (which are effectively the same thing in the workplace).

2. Simplicity is better. If your standards document is pages long, it will be immediately ignored by a busy developer. In my world, the best document is no more than a page long. For a coding standard, I would be inclined to create a single sheet of example code. Provided that I'd successfully made the business case above, I would then say to the team, "Make your code look like this, please."

If you make the mistake of involving more senior management in this discussion, point 1 is even more important. They're going to be surprisingly brutal when it comes to understanding exactly how many dollars your coding standards will save the organization. You can win that argument if you think it through carefully: e.g., reducing debugging time cuts hourly cost as people are able to check off lists of bugs quickly. That's cash money saved.

If you make the mistake of threatening the engineers (e.g., the suggestions of termination above), there's a very high probability that you'll eventually be featured on the Daily WTF.

If you manage to succeed at points 1 and 2, the actual support for standards validation are already well understood. Make sure that as much as possible is handled in the IDE (control-shift-F to format properly, etc.), automated checking tools, etc.

The technical methodology is the easy part. The people problems are always the hardest (and the most important).

Answer 30

You could try offering them badges and reputation points. ;)

Seriously though, maybe some kind of "gold star/frowny face" system would motivate them through competition with one another, and maybe lighten the mood a bit... and I don't actually mean give them gold stars or frowny faces, cause that would be silly. Just some general reward system.

Answer 31

By enforcing code reviews based on the coding standards document and reject if the coding standards are not followed and by including a code beautifier (http://sourceforge.net/projects/gcgreatcode) in the standard build process. After a clean compile (no errors, no compiler warnings, no lint warnings,..) call greatcode.

Answer 32

I was charged with the responsibility of rolling out standards within our company. There are a number of things that have worked and a number of lessons that I have learned. The development community that would be following these standards was about 25 strong. The first thing to ascertain is the culture and appetite for standards as this will dictate your approach. One of the first things you will need is management buy-in. There may be project managers whose only perspective on standards is to perceive that they contribute to slipped deadlines. Fundamentally you need buy-in from senior technical managers who recognise that code reviews and standards are fundamental tools for tacking "Technical Debt." There are any number of justifications and resources out there describing this, but this is a huge challenge for any organisation with a large legacy code base.

If technical debt is a problem, then your organisation will already have issues with development timescales, testing, burgeoning support backlog, and possible even high staff turnover. These should all be possible to quantify (roughly) should you need to highlight the challenges to senior management.

The next people you need to persuade are the developers themselves. You will have some who are positive and some who are against this. In our company we formed a 'standards' group, and invited a cross-section of developers to sit on this. When the standards documents were introduced, the standards group discussed and agreed them before rolling them out.

We found it important to put across an inclusive and positive message. "WE" will be doing this, not "YOU" must be doing this. Statements like, "The Standards will help us all learn more, and will make our lives easier in the long term" also help. Present the standards as a tool for learning and picking up new skills (which you will, invariably).

Off the back of the standards were formal code reviews. The process for doing this may well have be tailored to your organisation's individual needs, but the most important thing is to put across that a code review isn't a criticism. It’s also important not to tie a personal performance to the number of failed code review they have. A general observation on their general willingness to support the process should suffice.

In our organisation, post-introduction of standards (especially early on) found them to be fairly fluid and subject to change (as we learned more about their relevance and applicability), so we had the issue of communicating changes to the development community. Rather than pinging out a document for developers to peruse at their leisure, we held training days and briefing sessions. These are times that developers are away from their desks, and helps individual feel that they have the opportunity to challenge and question. In these training sessions we also presented new techniques and ideas, again, with the message “This is really useful, it will make OUR lives easier”.

Periodically, we have a standards review session where everyone can feed back on what they feel does and doesn’t work. This all puts across the message that developers aren’t being dictated to, and that long-term we’re just trying to make their lives easier. Certainly a good grasp of standards and best practice (and involvement in them) will look good on anyone’s CV!

Any estimates for timescales should factor in code reviews, and management should recognise that for a short period of time, at least, following the introduction of standards, ‘output’ may fall.

Any resistance you do get will almost certainly be passive, people will refuse to follow the standards or code reviews. This is difficult to deal with (and can sometimes be unpleasant if you are friendly with them). If you have an adequate system for recording code reviews and participation, then you will have some metrics for feeding into performance reviews (though I would only advocate this as a last resort). This is where your management buy-in will be most important.

Finally, there will be those scenarios where, when chips are down, we have to just get our heads down and code like crazy. These often see standards go out the window. The important thing to do here is have standards and reviews so embedded into your process that it just isn’t possible.

I could probably write a whole essay on this, and go into much more detail. I hope the above makes sense as it is quite a brain dump!

Answer 33

First have a coding sensible coding standard approved by a veteran that everyone respects. Don't give that job to some MBA quality assurance guy who knows nothing about programming or who wants to enforce the first document he/she finds on the Internet. Above all, take comments and suggestion from everyone in the team.

Next, be aware that no one is going to read that document. Not only coding style is a religious matter for most of us, we have too much to read anyways and usually procrastinate on that matter.

The best way is to make it part of the building process. If the code does not compile your programmers are going to fix it. If they have to do more clicks... Also you could have a pre-commit script (svn has those pre-hooks). Basically, it is a process that can be automated, and that is right the stuff that everybody avoid doing manually.

However! Be aware of:

• if the tool is enforcing some other style (configuration errors)
• List item

legacy code

Answer 34

I wouldn't worry about it until I'm team leader and getting paid to worry about that stuff. If he writes awful code, let it be and do your own thing, you probably aren't being paid enough to worry about it anyway.

Answer 35

You need to learn serenity! This is a common situation. Even as you get more senior and are more able to affect things, you won't be able to make a perfect coding situation. Just try to do the best job you can, and be a good example yourself.

Know-it-all-superstar co-workers is also something that will never go away. There are a few things you can do though.

Answer 36

Employee? Here it is - I send such people to HR for a talk about work ethic, threatening termination.

Following standards is not optional. As an employee - or contractor - following coding styles is mandatory. Not doing so, willfully, is breach of contract. Including having them pay for an external consultant for cleaning up the mess. Including - upon repeat - terminattion for violation of contract.

This is simple - if I employ you as programmer on my team, and you do not follow orders and make yourself usless on the team, you have no right to be on said team.

Answer 37

If it's really a big deal, you're going to have to prove to them why they're wrong.

They catch and suppress Throwables

It shouldn't be very hard to come up with some test input that causes a catastrophe.

return nulls

This isn't as serious as suppressing Throwable, but can still cause problems. Show them where their code is causing NullPointerException to be thrown. You should also show them what to return instead of null (empty array, Null Object, etc.) and how much easier it is to work with in the calling code.

concatenate Strings in large loops

This isn't nearly as bad. If it were me, you'd have to show me that the loop in question was the bottleneck in the system and that the concatenation was slowing things down significantly. Benchmark the application and find out.

For any practice that you see as a problem you need to be able to demonstrate two things:

1. Why it's wrong.
2. The right way to do it.

If you can't do both, then you're not giving them enough reason to change their habits.

Answer 38

If your co-workers and management don't care about code quality, you cannot force them to care. If you made a genuine attempt to convince them and you are being ignored, it is not really your role to take it any further.

I'm actually tired of rewriting that awful code on my own.

I think it is time to quietly start looking for a new job. Meanwhile, resist the temptation to rewrite the crap code for reasons other than fixing bugs. And try and get the culprits to fix their own bugs.

Having said that, it is possible that the team lead cares more about this than he is letting on. He may simply not be in a position to take the necessary action to deal with the poor quality culture. For example, if the project is running behind, getting rid of staff may not be an option. Or maybe he does not have any real clout on staffing issues ... and the culprits know it.

Answer 39

http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

http://psycnet.apa.org/?fa=main.doiLanding&doi=10.1037/0022-3514.77.6.1121

Also an explanation of why most drivers perceive themselves as being abover average. The base problem is that to accurately evaluate your own competence you need to be competent enough to do so. The least competent are also the least aware of the skills in which they are deficient.

In your position I'd consider some of the advice above as well.

Answer 40

I'd probably attack the problem somewhat indirectly. Instead of pointing to his code and saying it needs to get better (or something on that order), you can go back to the specification for what you're supposed to be doing. It may already have requirements (or at least guidelines) that he's violating; if so, you have a real basis for saying that what he's doing really isn't all right.

If it doesn't already contain any such requirements, depending on how fluid the specification is, you may be able to work toward getting some such requirements (or at least guidelines) added.

Another possibility is to consider a set of company wide coding guidelines. If there's one already in place, he may be violating its requirements. If so, you (again) have a real basis for saying he needs to change his ways. If there's not one in place already, you might consider trying to get one put in place.

Just as there's always at least one coder who does lousy work, there's also always at least on bureaucrat who will welcome more rules and regulations. With a bit of looking you can almost certainly find at least one like that. Chance are pretty good that you can find somebody like that in a position that makes it at least somewhat reasonable for such a set of guidelines to fall within his area of responsibilities.

Go to him with a suggestion (not mentioning the current problem directly at all) that the company really should have a set of guidelines for how coding is done. One way to sell this kind of thing is to mention the ISO 9000 (and related) standards, and point out how these really are best practices for the business even if they don't intend to be certified as complying with the standards.

Be prepared though: when/if you do that, you'll almost certainly be (effectively) volunteering to run the effort to produce the guideline. If you're junior enough, they might decide to officially put somebody else in charge, but they're probably going to see it as "your idea", so chances are you'll still be doing most of the work. That being the case, if you're going to go this route, be prepared to do it "for real". If you really do produce a company-wide guideline, you really need to think in terms of what fits the company as a whole, not just dealing with your pet peeves about the coding of the person in question.

Also be aware that this sort of thing can have a substantial effect on your career -- if what you mostly want is to be a guy who sits in his cubicle and gets left alone to crank out code, this may not be a good idea. It will almost certainly make you more visible, and as a more or less managerial sort of person, not just a coder (and that's likely to follow you to your next job when/if you move). That's not always bad, but you need to think about whether it's what you really want.

Answer 41

Give them their own (each other's) old code to fix, extend, maintain, modify, refactor, optimize and so on. Preferably each several pieces of code from multiple others.

Request reports on quality of code they had to work with.

Hand the reports to original authors of the code.

Answer 42

Make it a part of their job description on their yearly review, and tie it to their yearly bonus if they succeed.