Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Dealing with sloppy code

by BMaximus (Chaplain)
on Nov 17, 2005 at 17:10 UTC ( #509476=perlmeditation: print w/ replies, xml ) Need Help??

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?

BMaximus

Comment on Dealing with sloppy code
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.

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

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.
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
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:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
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.
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.
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;
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".

Re: Dealing with sloppy code
by samizdat (Vicar) on Nov 18, 2005 at 15:00 UTC
    Take three deep breaths.

    First off, remember that the code works. Most sloppy code is the result of time pressure and improperly defined, rapidly changing specifications. When in doubt, ask the original programmer if your understanding of his code is correct. Stay away from making suggestions. You will generally get an explanation of the development sequence that led to the problem, and, often, the OP will -- on his own -- do some rewriting of the most egregious common modules.

    Concentrate on your own code in all its glory. When you need to interface with another's code, discuss the API at the highest level possible. "I've found that this works" and "Will this help?" work better than "Don't do that".

    Come from the place that everybody wants to excel and would if they knew how. It's just as easy (in terms of keystrokes, anyway :) to write clean Perl code as it is to write crap. Do not buy extra copies of quality texts, but do make it known that yours are available for study and that you've been helped by reading them. Be available as a sounding board, and you'll discover that the code around you starts to get better. Compliment improvements!

    On a personal note, I have always found the above advice hard to stick to, but when I do, I'm lifted up to the position of de-facto project leader by my peers because people do want things done right. The most important part of that advice is to do your own job well. Until you do that, everything else you say is noise and does more harm than good.

    Don Wilde
    "There's more than one level to any answer."

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://509476]
Approved by ww
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (13)
As of 2014-09-30 11:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (364 votes), past polls