I've noticed some programmers do not seem to have much desire to write clean, organized, and readable code. What are some good ways to encourage consistent indentation, good naming of variables and functions, organized file structures, among other things?
Absolutely, code review should be part of quality procedures and it should be a peer review process. Programmers should also be involved in creating the coding standards so that they are useful. Also you can't do quality in isolation, SME's, analysts, testers, managers all have to pitch in.
MikeAinOz
2010-09-29 23:11:22
A:
Personally, I would give them someone else's badly written code, and ask them to explain. However, since you said fellow programmers, I am guessing you are not the supervisor.
Mandatory code reviews, coding standards, and if they have to read part of your code, give them some horribly written code one time, and let them decipher...
Sagar
2010-09-29 22:16:13
A:
Mandate (or encourage your boss to mandate) peer code reviews. At the very least, have another programmer skim written code at some point. This also gives your company more chances to catch more bugs before they bite some one.
aschepler
2010-09-29 22:16:43
A:
You could get them to work on legacy code, so that they feel the pain of trying to change sloppy code.
You could also have an approval system, where they are not allowed to work on anything new untill their code is approved.
Another way is those who write the best code get to work on the most interesting projects.
Shiraz Bhaiji
2010-09-29 22:16:51
+6
A:
Lead by example.
Become a champion of the patterns and standards that work for you.
Code reviews.
Suggest books that you've found helpful and that promote neater code.
Be blunt; I tell team members all the time what I like and don't like about their code. More importantly, I tell them why.
EDIT: I ask for code samples in the beginning of the interview process. Pretty code doesn't always mean a great developer, but sloppy, unreadable code is never the mark of a good engineer.
I may be a little picky; I'm the guy who spell checks code comments.
Tim
2010-09-29 22:21:03
Great points, but sometimes people need more "encouragement" in order to care. Sometimes you just need a big stick and a strong arm.
Ryan Ternier
2010-09-29 22:36:48
@Ryan - +1 on your comment. It also depends on the type of environment you are working in. I manage senior consultants, and as such I pick and choose the right people and fire the ones that don't "get it" pretty quickly and everyone knows they are paid the "big bucks" to perform. Conversely, in a product group you often have much more junior individuals that need standards mandated to them, and who also just need to be mentored and taught the right way. At some point in our careers, we were all mentored and taught by someone else.
Tim
2010-09-29 22:53:16
+1 for "spell checks code comments” I wish more people would show such care for their craft.
Nescio
2010-09-29 22:54:34
@Tim - You are correct. In this day an age the majority of younger developers need the constant monitoring (I didn't say all,lower those pitch forks!). But once they get that the grass is greener where you water it, it goes better in everyone's favour.
Ryan Ternier
2010-09-29 23:04:04
+4
A:
The only way you get away with writing unreasonably difficult code is if one of two conditions exist:
You write the code, throw it over the wall to QA/support/whoever, and never have to see it again once it works the first time ("mostly").
You are a Vulcan and can read/fix anything you've ever written, and because you are the only one who ever develops within that code you get away with it.
To improve readability, ensure that neither of these conditions exist. The best way to do that is never to let somebody work alone. This way, the path of least resistance is to produce code that at least one more person can read. The programmer in question probably dislikes all-the-time fighting about his code even more than he dislikes paying attention to readibility.
In the (odd) case where the developer refuses to work with anyone else and their unreadable code continues to cause problems, fire them, because they are not a valuable asset.
The idea of mandating code readability is kind of perverse. The carrot is more valuable than the stick, and if you give an engineer rules, they'll spend all their time finding loopholes instead of actually contributing value.
Andres Jaan Tack
2010-09-29 22:27:27
This sounds like Office Space: "My only real motivation is not to be hassled."
Andres Jaan Tack
2010-09-29 22:36:42
you know what keeps my code looking good? Not wanting to be called out by more senior devs. That would bring me shame, and I'd be humiliated. Why isn't my answer legitimate?
jim
2010-09-29 22:47:45
Snarkyness is better left to comments, and comments don't expose you to downvotes.
Robert Harvey
2010-09-30 03:07:04
I'm sure that being afraid of public humiliation will keep you from being the _worst_ you can be, but I don't think that's _nearly_ the best answer. It has the nasty side-effect of poisoning the workplace.
Andres Jaan Tack
2010-09-30 06:19:08
I haven't found that to be true Andres. I've found that a little good natured humiliation can do wonders. If youre a dev with so much ego that you can't take a little ribbing about your code during group reviews you shouldn't be a dev in the first place. I find ego to be the biggest work place poison.
jim
2010-09-30 16:22:49
+1
A:
Engage the staff. Don't do anything to publicly humiliate them (come on who does that!?, jim no need to reply), but do encourage them. Positive reinforcement works way better than negative.
Sure lead by example, but take the time out of your day to work with the people that need the help. Give people goals.
Don't just say "it's the rule. If you don't do it we'll make you eat toothpaste with a toothpick".
We (developers) are logical. And, if a developer cannot understand the logic of code readability, especially when talked to by a manager/higher up, maybe something has to change, and that's for those involved to decide.
Ryan Ternier
2010-09-29 22:43:06