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

Answer 1

Have code reviews, and start by reviewing YOUR code.

It will put people at ease with the whole code review process because you are beginning the process by reviewing your own code instead of theirs. Starting off with your code will also give them good examples of how to do things.

Answer 2

Bad naming practices: Always inexcusable.

And yes, do no always assume that your way is better... It can be difficult, but objectivity must be maintained.

I've had an experience with a coder that had such horrible naming of functions, the code was worse than unreadable. The functions lied about what they did, the code was nonsensical. And they were protective/resistant to having someone else change their code. when confronted very politely, they admitted it was poorly named, but wanted to retain their ownership of the code and would go back and fix it up "at a later date." This is in the past now, but how do you deal with a situation where they error is ACKNOWLEDGED, but then protected? This went on for a long time and I had no idea how to break through that barrier.

Global variables: I myself am not THAT fond of global variables, but I know a few otherwise excellent programmers that like them A LOT. So much so that I've come to believe they are not actually all that bad in many situations, as they allow for clarity, ease of debugging. (please don't flame/downvote me :) ) It comes down to, I've seen a lot of very good, effective, bug free code that used global variables (not put in by me!) and great deal of buggy, impossible to read/maintain/fix code that meticulously used proper patterns. Maybe there IS a place (though shrinking perhaps) for global variables? I'm considering rethinking my position based on evidence.

Answer 3

Suggest a better alternative in a non-confrontational way.

"Hey, I think this way will work too. What do you guys think?" [Gesture to obviously better code on your screen]

Answer 4

I can't emphasize patience enough. I've seen this exact sort of thing completely backfire mostly because someone wanted the changes to happen NOW. Quite a few environments need the benefits of evolution, not revolution. And by forcing change today, it can make for a very unhappy environment for all.

Buy-in is key. And your approach needs to take into account the environment you are in.

It sounds like you're in an environment that has a lot of "individuality" to it. So... I wouldn't suggest a set of coding standards. It will come across that you want to take this "fun" project and turn it into a highly structured work project (oh great, what's next... functional documents?). Instead, as someone else said, you'll have to deal with it to a certain extent.

Stay patient and work toward educating others in your direction. Start with the edges (points where your code interacts with others) and when interacting with their code try to take it as an opportunity to discuss the interface they've created and ask them if it would be okay with them if it was changed (by you or them). And fully explain why you want the change ("it will help deal with changing subsystem attributes better" or whatever). Don't nit-pick and try to change everything you see as being wrong. Once you interact with others on the edge, they should start to see how it would benefit them at the core of their code (and if you get enough momentum, go deeper and truly start to discuss modern techniques and the benefits of coding standards). If they still don't see it... maybe you'll need to deal with that within yourself (especially on a "fun" project).

Patience. Evolution, not revolution.

Good luck.

Answer 5

I don a toga and open a can of socratic method.

The Socratic Method named after the Classical Greek philosopher Socrates, is a form of philosophical inquiry in which the questioner explores the implications of others' positions, to stimulate rational thinking and illuminate ideas. This dialectical method often involves an oppositional discussion in which the defense of one point of view is pitted against another; one participant may lead another to contradict himself in some way, strengthening the inquirer's own point.

Answer 6

People writing bad code is just a symptom of ignorance (which is different from being dumb). Here's some tips for dealing with those people.

• Peoples own experience leaves a stronger impression than something you will say.
• Some people are not passionate about the code they produce and will not listen to anything you say
• Paired Programming can help share ideas but switch who's driving or they'll just be checking email on their phone
• Don't drown them with too much, I've found even Continuous Integration needed to be explained a few times to some older devs
• Get them excited again and they will want to learn. It could be something as simple as programming robots for a day
• TRUST YOUR TEAM, coding standards and tools that check them at build time are often never read or annoying.
• Remove Code Ownership, on some projects you will see code silos or ant hills where people say thats my code and you can't change it, this is very bad and you can use paired programming to remove this.