How to deal with team members writing bad code [duplicate]

Question

This question already has answers here:

How do you disarm a cowboy coder? [closed] (5 answers)

Closed 6 years ago.

Our team consits of junior and senior developers. Problem I am facing is with the code written by seniors. They are not following MINIMUM coding standards. I am also still learning but I wouldn't declare the inline style or give improper names for variables and controls. I tried to mention it indirectly but they were like we can take it up later and since its agile, we should move on. But my problem is when I start working on my task, it makes me feel bad and I would focus more on refactor rather than on my task. I am not sure how to deal with this situation.

PS: I am sure this question has been asked many times. But any advise is much appreciated.

Answer 1

A couple of things.

1. Don't assume that your seniors don't know what they're doing. They may have very good reasons why they made the decisions that they did; ask them why (in a non-argumentative way).

2. Code that is already written, backed by unit tests, and declared functionally complete by your superiors can be safely ignored. That's what you should do with it: ignore it, until it becomes necessary to further maintain it, for whatever reason.

3. Based on your cursory description, it sounds like your team is under significant time pressure. Compromises are made under those conditions; that's just the way it is.

Choose your battles wisely. Only fight the ones that need fighting.

Answer 2

They are not following MINIMUM coding standards.

If it's not your job to police the coding of others, then don't do it. It's a classic way for juniors to make a bad name for themselves.

See this question for a similar discussion: https://softwareengineering.stackexchange.com/questions/78100/how-do-i-tell-a-senior-programmer-that-i-disagree-with-him

Related: A blog post I wrote about disagreeing, and part of that is knowing your place and when it's appropriate to disagree and when it's not: How to disagree without being disagreeable

Answer 3

As others have mentioned, you should ask about the senior developer's choices in a non-confrontational way, but it might also be worth it to look into a few things.

First of all: is there a coding standard that the project follows? If there is no coding standard defined, then nobody is breaking the coding standard. The 'standard' may simply be to make new code look similar to the old code. That's an unfortunate position to be in, but an ad-hoc coding standard is still a coding standard.

If there is a coding standard: who ensures its implementation? Are all developers responsible, is it handled during review periods, etc.

I'll give you my example: I came onto a project that's just starting out. We have senior members, but mostly juniors(myself included). As it turned out, I was the one who was most concerned about a coding standard. Our company and QA policies dictate that we have a standard, and since I was the one who brought it up it was my job to find one.

That turned out to be super easy. There's a standard for Java set by Oracle, which makes that the obvious choice. Next, I found a tool for Java called Checkstyle, which enforces coding standards for you. Every time you make a change and save a file, Checkstyle runs over the file for any violations of the coding standard you have, and high lights all violations just like a warning. Additionally, it does a few static analysis tasks: N-Path complexity, cyclomatic complexity, etc. After that, I looked into Eclipse's formatter and found I could make that conform to our coding standard as well. So now, after a minimal amount of set up, we have a tool that:

• High lights coding standard violations
• A formatter that can be invoked with ctrl + shift + F
• Zero maintenance
• No time is spent in code reviews for trivial coding standard issues(tab here, space there, comment needed here, etc)

So, ultimately, to really deal with maintaining a coding standard, I would:

1. Ask what the current standard is, is it defined somewhere, and are all developers aware of it?
2. Get a plan ready - do some homework and search for tools in your project's language that can help you do what I did. Seriously: having a coding standard in place that everyone follows is great. I ended up making it so easy to do that no one had a reason not to follow it.
3. Once you have a plan, try talking about it to your supervisor. Tell them your plan, and more importantly: tell them how this could save them time in the future by having fewer defects in the code.

Answer 4

Exercise the practice of openness in a professional setting - if you feel that their code may be improved and you have a good reason to assert they should be doing it differently, there should be nothing in your way to suggest it (as long as you aren't condescending or such). If you work somewhere where openness is frowned upon, I don't know if that's particularly healthy. They may have some excellent insight as to why they're doing something that you didn't notice or the opposite - someone is bound to learn something by just asking questions :)