How do you tell someone they're writing bad code? [closed]

Answer 1

Instead of having them write code, have them maintain their code.

Until they have to maintain their steaming pile of spaghetti, they will never understand how bad they are at coding.

Answer 2

Start doing code reviews or pair programming.

If the team won't go for those, try weekly design reviews. Each week, meet for an hour and talk about a peice of code. If people seem defensive, pick old code that no one is emotionally attached to any more, at least at the beginning.

As @JesperE: said, focus on the code, not the coder.

When you see something you think should be different, but others don't see it the same way, then start by asking questions that lead to the deficiencies, instead of pointing them out. For example:

Globals: Do you think we'll ever want to have more than one of these? Do you think we will want to control access to this?

Mutable state: Do you think we'll want to manipulate this from another thread?

I also find it helpful to focus on my limitations, which can help people relax. For example:

long functions: My brain isn't big enough to hold all of this at once. How can we make smaller pieces that I can handle?

bad names: I get confused easily enough when reading clear code; when names are misleading, there's no hope for me.

Ultimately, the goal is not for you to teach your team how to code better. It's to establish a culture of learning in your team. Where each person looks to the others for help in becoming a better programmer.

Answer 3

If you have even a loose standard of coding, being able to point to that, or indicating that you can't follow the code because it's not the correct format may be worthwhile.

If you don't have a coding format, now would be a good time to get one in place. Something like the answers to this question may be helpful: https://stackoverflow.com/questions/4121/team-coding-styles

Answer 4

I frankly believe that someone's code is better when it's easier to change, debug, navigate, understand, configure, test and publish (whew).

That said I think it is impossible to tell someone his/her code is bad without having a first go at having him / her explaining what it does or how is anyone supposed to enhance it afterwards (like, creating new funcionality or debugging it).

Only then their mind snaps and anyone will be able to see that:

• Global variables value changes are almost always untrackable
• Huge functions are hard to read and understand
• Patterns make your code easier to enhance (as long as you obay to their rules)
• ( etc...)

Perhaps a session of pair programming should do the trick. As for enforcing coding standards - it helps but they are too far away from really defining what is good code.

Answer 5

There's some really good advice in Gerry Weinberg's book "The Psychology of Computer Programming" - his whole notion of "egoless programming" is all about how to help people accept criticism of their code as distinct from criticism of themselves.

Answer 6

Privately inquire about some of the "bad" code segments with an eye toward the possibility that it is actually reasonable code, (no matter how predisposed you may be), or that there are perhaps extenuating circumstances. If you are still convinced that the code is just plain bad -- and that the source actually is this person -- just go away. One of several things may happen: 1) the person notices and takes some corrective action, 2) the person does nothing (is oblivious, or doesn't care as much as you do).

If #2 happens, or #1 does not result in sufficient improvement from your point of view, AND it is hurting the project, and/or impinging on you enough, then it may be time to start a campaign to establish/enforce standards within the team. That requires management buy-in, but is most effective when instigated from grass roots.

Good luck with that. I feel your pain brother.