Recently I became a part of the gainfully employed once again in the field of Perl programing. However as part of my work like some many others here I have to deal with code that others have written. Some of this code that I'm coming across is downright horrific right down to the flow of the program. I'd like to know how you deal with your coworkers sloppy code. Do you just bite your lip and do what you do best? Or do you let them know that although the code works as far as readablility and maintainablility the code they create is a monster worth its own B rated horror flick? Do you break it to them that they need to read the Perl Best Practices Book and take it to heart? How do you tell them if you do?
|
Re: Dealing with sloppy code
by adrianh (Chancellor) on Nov 17, 2005 at 17:17 UTC
|
Get copies of Perl Medic, Perl Best Practices and PDTN and sprinkle around the dev room.
Install perltidy to save your sanity with formatting.
Show, don't preach.
Don't spend your time telling everybody how shite the code is, instead spend time working with people showing how nice code (and improving bad code) makes everybody's life easier.
| [reply] |
Re: Dealing with sloppy code
by Old_Gray_Bear (Bishop) on Nov 17, 2005 at 18:07 UTC
|
One thing to look out for is making too many changes at once. You can usually get away with a little bit of refactoring at a time. (Well I was in there to fix this bug, and I had a devil's own time figuring out that the variable $aa was actually the base pay-rate and $aaa was the differential rate, so I made a mass change in addition to fixing the two lines that were broken.) People will be more accepting of several small changes spread out several days, rather than one large one. Over time, you will end up cleaning up a lot of dreck with a lot fewer complaints.
"One step at a time, I will walk around the world." -- Aral Vorkosigan
----
I Go Back to Sleep, Now.
OGB
| [reply] |
Re: Dealing with sloppy code
by dragonchild (Archbishop) on Nov 17, 2005 at 19:29 UTC
|
- Make sure this stuff is in a source-code repository. I recommend Subversion, but anything is better than nothing. If your team refuses, you can run subversion in a single-user mode under your home directory.
- The very next step is to write tests that verify what the code is supposed to do. If, as is likely, you cannot get a written spec, write tests against what it does right now.
- Run your testsuite under Devel::Cover, to make sure you got it all. 95% and higher is good.
- Refactor one tiny piece at a time, making sure the testsuite passes every time, verifying that the coverage is always at least as good as before, then check it in.
As for your coworkers ... my experience is that people code in the style they're handed. If you clean things up a bit, then people will continue the trend. It's when there's a broken window that people stop caring. Fix the broken windows and you'll be better off.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
Re: Dealing with sloppy code
by ptum (Priest) on Nov 17, 2005 at 18:14 UTC
|
You say tomayto, I say tomahto. Sometimes 'horrific code' is just another way to do it, perhaps not the best way, but it often gets the job done. Don't confuse your style preferences with some Higher Standard. Nobody appreciates being bashed, but most people will pick up on a good example. I would recommend starting weekly code reviews, and gently making suggestions to improve code. Offer up some of your own code for examination and humbly accept even flawed criticism -- this will set the tone for constructive and collective code improvement.
I recently took a C++ course and was surprised to find that I had allowed myself to get into some sloppy programming habits, partly because Perl is so forgiving.
I guess the main ingredients in dealing with others' code are two cups of humility and a dash of a good sense of humor. | [reply] |
Re: Dealing with sloppy code
by bageler (Hermit) on Nov 17, 2005 at 22:12 UTC
|
Usually when I run into this, it's because a great guy was given horrible limitations on getting the work done. By the time they bring me in to clean up, it's so far behind schedule that I have free reign over what to do and how long to do it. So I review the code with the original programmer, who usually knows what he did wrong and explains how it got that way. Then I rewrite the code, and go over it with the original coder, not only to show him how I do it differently (and hopefully some clean coding style rubs off) but to see if he has any criticism of what I've done. | [reply] |
Re: Dealing with sloppy code
by jdhedden (Deacon) on Nov 17, 2005 at 21:11 UTC
|
Most of the time when this has occurred to me, the original programmer is not around. Regardless, I rewrite the code.
If the programmer is a newbie, I may try to work with them to change their ways.
If not, I don't bother - their bad habits are ingrained, and I've learned by experience that you can't teach a bad dog good tricks. I discuss the issue with my manager. It's best to let managment know that they are a potential problem, and let them deal with it.
Remember: There's always one more bug.
| [reply] |
Re: Dealing with sloppy code
by zentara (Archbishop) on Nov 17, 2005 at 18:55 UTC
|
I'm probably stating the obvious, but running code thru perltidy
often helps to clarify what is going on. Also I like ptkdb ( the Tk front end to the perl debugger), it lets you step thru code, set break points, watch variables, and visually see how the code jumps. After some initial analysis, you can start separating code out into sections, then subs, etc.
I'm not really a human, but I play one on earth.
flash japh
| [reply] |
Re: Dealing with sloppy code
by samizdat (Vicar) on Nov 18, 2005 at 15:00 UTC
|
| [reply] |
Re: Dealing with sloppy code
by vishi83 (Pilgrim) on Nov 18, 2005 at 06:07 UTC
|
Hi maximus !!
Already lot of discussions hav gone into this topic..
But i thought of adding some of my points to that
Ther r lots of ways to deal with sloppy code..
You can maintain uniformity in code developed by your developers ..
You can clean up your code using perltidy. Download it from
sourceforge
Read the documentation too..
Another thing i would suggest is to make use of
Perl checkstyle module
Do refer the Module::CheckStyle in CPAN
This module has got lot of configuration options..
the only thing u need to do is to give the path of your .pl file while using this module ...
Your script can also be documented using PODs ..
Thats it man !!!
Thank you ,
vishi83
A perl Script without 'strict' is like a House without Roof; Both are not Safe;
| [reply]
[d/l] |
Re: Dealing with sloppy code
by ciderpunx (Vicar) on Nov 18, 2005 at 10:46 UTC
|
Do you break it to them that they need to read the Perl Best Practices Book and take it to heart? How do you tell them if you do?
As others have pointed out one geek's meat is another geek's poison.
I think the real issue here is a communication one, maybe what needs to happen is that you all get together and agree a set of coding standards?
As programmers it's easy to forget that human beings tend not to work in a straightforwardly algorithmic way. Generally people want to be involved in the decisions about how they're going to work, and don't appreciate Johnny-Come-Lately telling them everything they've been doing is wrong.
So get together, maybe with the Best Practices book, or Effective Perl there and agree on your standards as a team. I'd bet that you'd all benefit from the process and you'll certainly come up with a 'livable-with' standard, even if it means you have to compromise on some of what you consider "the best way to do things".
| [reply] |
|
|
