How do you tell someone they're writing bad co

Question

I've been working with a small group of people on a coding project for fun. It's an organized and fairly cohesive group. The people I work with all have various skill sets related to programming, but some of them use older or outright wrong methods, such as excessive global variables, poor naming conventions, and other things. While things work, the implementation is poor. What's a good way to politely ask or introduce them to use better methodology, without it coming across as questioning (or insulting) their experience and/or education?

Answer 1

Start a wiki on your network using some wiki software.

Start a category on your site called "best practices" or "coding standards" or something.

Point everyone to it. Allow for feedback.

When you do releases of the software, have the person whose job it is to put code into the build push back on developers, pointing them to the Wiki pages on it.

I've done this in my organization and it took several months for people to really get into the hang of using the Wiki but now it's this indispensable resource.

Answer 2

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 3

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 4

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.

Answer 5

I have a similar senario with the guys i work with.. They dont have the exposure to coding as much as i do but they are still usefull at coding.

Rather than me letting the do what they want and go back and edit the whole thing. I usually just sit them down and show them two ways of doing things. Thier way and My way, From this we discuss the pro's and cons of each method and therefore come to a better understanding and a better conclusion on how should we go about programming.

Here is the really suprizing part. Sometimes they will come up with questions that even i dont have answers to, and after research we all get a better concept of methodology and structure.

1. Discuss.
2. Show them Why
3. Don't even think you are always right.. Sometimes even they will teach you something new.

Thats what i would do if i was you :D

Answer 6

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.