Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

runrig (3385)

runrig
  dougwNO@SPAMcpan.org

Just another perl hacker somewhere near Disneyland

I have this homenode [perlmonks.org] of little consequence on Perl Monks [perlmonks.org] that you probably have no interest in whatsoever.

I also have some modules [cpan.org] on CPAN [cpan.org] some of which are marginally [cpan.org] more [cpan.org] useful [cpan.org] than others.

Journal of runrig (3385)

Friday August 08, 2008
09:17 PM

You suck or silence?

[ #37136 ]
When someone posts a "utility" on the company intraweb, and it's perl, and it's about 900 lines long, with no strict or warnings, has no indentation, needlessly builds strings and splits to an array when qw() would've been appropriate, needlessly uses ".*" in regular expressions, (mis)uses subroutine prototypes, has lots of repeated code that could be factored into subroutines, and lots of other things you'd expect to see in the sort of code that has all the previous issues, and you've already written a library to do the same thing and more (in fewer lines...though slightly more if you count the documentation), what do you do?

List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

You suck or silence? 13 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Are those the only two options? So maybe the code sucks, but maybe the guy is a novice coder too. Surely you can come up with something better than "you suck". Get your attitude right before ou deal with his.

    • Surely you can come up with something better than "you suck".

      Surely I can, but "you suck" golfs better than "constructive criticism" in a blog title, and feels more satisfying in a rant :-)

  • Why do you need to do anything? Are you the code police? What do you want to achieve?
    --

    --
    xoa

    • Why do you need to do anything?

      Well, "doing nothing" would be pretty much the second option offered in the original subject...I was maybe considering something in between the two.

      What do you want to achieve?

      I'm not sure...I do feel like something should be done, but that maybe it's best if nothing is done. Maybe I'd like to just raise standards a bit, and do something about the proliferation of crap perl code that helps feed the notion of some that all perl code is crap...and I'd also like to achieve wo

  • The question that you didn't answer is: does it do the job it was designed to do, or is it, OTOH, very buggy?

    Don't fix if it isn't broken.

    There's no reason to refactor the code if the net gain, i.e. working better, is zero.

    • It generates a report of problems with a certain type of file. There are a couple of major but easy to fix bugs. While it's ok at generating a report of possible/probable problems, it's not to be relied upon for absolute correctness/wrongness of the file...it's way too easy to trip up the parsing of the file and get false positives and negatives (e.g. comments are being parsed the same as commands). As long as there is no decree of "your file must pass this test", I won't yell too loudly.

  • Wait until MJD finishes his Program Repair Shop and Red Flags book, then order it and give it to the developer in question, so that in the future, they may write better code.

    —————— ——————

    For the moment, I would ask: is this program still being edited? If so, it’s justifiable to take time to fix it, so give some code reviews; point out a handful of improvements that will have the largest effect. Do this iterative

  • "I saw XXXX and I thought you should know that I already have a library that does something very similar. If you need to extend it, make it more robust, etc, feel free to come and talk with me, because I may be able to save you a lot of work."

  • All the answers here make the assumption that someone, other than you, wants to improve the code. Going forward with only you wanting to change the code means that you'll be perceived as saying "This code sucks, and I think it should be done this way."

    If nobody sees a problem in the code, then your first task is to help the person see that life could be improved by improving the code. Coming in and saying "This could code be better" doesn't mean anything, because "better" is a fluffy word. Why is it b

    --

    --
    xoa

    • Which is what option #3 that I made up boils down to – wait until MJD finishes writing down good answers to these questions and then give them to the novice to read. I’m not entirely serious with that, but it’s not meant as as much of a joke as it might first seem, either.

      (I am quite looking forward to that book. I am nearly (though of course never completely) certain that it will hold no big revelations for me, yet I am equally confident that I will enjoy it.)

      • But "here, read this" is the same problem. The novice needs to want to change something, to get a benefit, in order to improve.
        --

        --
        xoa

  • Because you'll (tactfully I hope) be retraining the other coder.

    But why do that?

    To stop. or at least reduce, the number of times /in the future/ you have to deal with their crap.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.