in reply to Can you make it nicer?

I’m afraid that, were I your team-lead, I would, rather decidedly, vote down your change, and not permit it to move forward into production.   And here would be my two three reasons why:

  1. Although the existing code might “offend your personal sensibilities,” it is nonetheless obvious as to what it does.   I can, using nothing more than my two eyeballs and from this (looks to be, rather extreme) geographical distance, be pretty-darned sure that it works.   (Furthermore, you are not reacting to any outstanding bug-report that suggests that it does not work.)
  2. Your “replacement” code, on the other hand, is not “visually obvious.”   At first glance, and the second and the third, I have no idea what this code is supposed to be doing.   Thank-you for providing test cases, but once again, I cannot be sure that these test cases are complete or exhaustive.
  3. There is business risk associated with your “gratuitous” change, but without any apparent business justification.

Yes, I would make a mental note to be sure that, henceforth, you always had enough assigned tickets to deal with, that you nevermore felt that you felt that you had enough spare time to indulge any temptations to “distract yourself with things that ‘you thought’ needed to be ‘improved about’ stable production code that was in service.

I am, as usual, quite sure that “the downvote daemons” will jump-on this opinion ... as they have done with so many others ...but in my defense I would simply say that it boiled down to a pure-business decision:   “In some ways, we all work in a sewer.   We can’t be making decisions based on smells.”   Change, itself, is “the bugaboo” here.   The <<business risk | business cost>> intrinsically associated with any change at all (especially to “active” code such as this ...) is so extreme that it must never be undertaken lightly.

Replies are listed 'Best First'.
Re^2: Can you make it nicer?
by choroba (Cardinal) on Nov 19, 2013 at 10:58 UTC
    Let me disagree, even if the original code was not the worst example I could have brought up.
    1. I was staring at the code for a long time before I understood what it does (originally, there was inconsistent indentation, global variables with meaningless names, almost no whitespace). I had to run it to see whether the numeric constants were correct and what the behaviour was for larger numbers.
    2. Here I have to agree. I was not satisfied with my solution, that was why I asked here. To run an exhaustive test, you can modify the list to 
      q(), 0 .. 1e12

      [download]
      Reserve enough time, though.
    3. Business justification: I am the maintainer of the code. If the code changes only when fixing bugs, it will stay in the nineties and become unmaintainable. Without refactoring, the code becomes dead, and accumulates risk: at one point in the future, a bug or feature request will appear that will not be possible.

      Working with always enough assigned tickets to prevent any creativity leads to exhaustion. It will make me leave your company, which means «business cost»: you invested in the hiring process and in training me. Moreover, trust (both to expert opinions and business decisions) makes the working environment better.

    لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
[reply]
[d/l]
Re^2: Can you make it nicer?
by Anonymous Monk on Nov 19, 2013 at 02:10 UTC
    The downvote demons jump on your posts because it they look like a unicorn ate an APL keyboard and threw it all up. No one can ever figure out what you're trying to say because no one can ever ever ever read it.
[reply]

      No one can ever figure out what you're trying to say because no one can ever ever ever read it.

      No figuring out is required; the text effects merely signal the stench volume of the advice

[reply]
Re^2: Can you make it nicer?
by LanX (Saint) on Nov 19, 2013 at 00:59 UTC
    > it is nonetheless obvious as to what it does.

    ORLY?

    The original code is buggy for > 1e10, guess why!

    Cheers Rolf

    ( addicted to the Perl Programming Language)

    PS: Did anyone really expect you would contribute any code?

[reply]
      How exactly is it buggy for id > 1e10?

      I will have to side with sundialsvc4 here. The original code is immediately obvious and clear for a C programmer.

[reply]
        use Test::More tests => 1;
is('C', 'Perl', 'language');

        [download]
        لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
[reply]
[d/l]
Re^2: Can you make it nicer?
by marinersk (Priest) on Nov 20, 2013 at 09:26 UTC
    I would make a mental note to be sure that, henceforth, you always had enough assigned tickets to deal with, that you nevermore felt that you felt that you had enough spare time to indulge any temptations to “distract yourself with things that ‘you thought’ needed to be ‘improved about’ stable production code that was in service.

    I am thankful you are not in a position to exercise such childish mismanagement principles in my company.

    I am, as usual, quite sure that “the downvote daemons” will jump-on this opinion ... as they have done with so many others.

    It really doesn't occur to you at all that the reason you get downvoted so often is that you're both wrong and abrasive, does it?

    I pity you.

[reply]

In Section Seekers of Perl Wisdom