in reply to Feature or Bug ?

Let's say I have a subroutine that looks something like: 
sub dummy {
    no strict;
    no warnings;
    ${"$_[0]"} = $_[1];
}

[download]
Is that code buggy? Maybe ... maybe not. That code is unsafe, but unsafe is not necessary incorrect. You cannot evaluate a piece of code outside of its context.

Now, most of us are in the habit of evaluating a piece of code within a global context, because any piece of code may be used anywhere, but that's not always reasonable. The rules in my sig are ordered as they are for a reason. Good software follows rule #1. Great software needs rule #2, but the perfect is the enemy of the good.

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?

Replies are listed 'Best First'.
Re^2: Feature or Bug ?
by fbinard (Beadle) on Sep 16, 2005 at 01:45 UTC

    "My criteria for good software: ..
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?"

    (2) depends also somewhat on the person who comes in.

    Franck Binard
[reply]

      I may not necessarily have the same criteria for good software as dragonchild, but no, it shouldn't depend on the person who comes in. I think that's (part of) dragonchild's point.

      Anyone should be able to come in, make a change to some small part of the program, and be reasonably certain that everything else continues to work as before, with this modification. I do think this ideal is a wee bit lofty for any set of requirements that approach moderate complexity, but I think I see where he's coming from.

[reply]
        If you don't shoot for the moon, you'll never catch a star. No-one made it to the top aiming for the middle.
        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?
[reply]
      Absolutely. One of the hallmarks of the master programmer is that s/he programs with the intended maintenance programmer's level in mind. For example, the code I write for my CPAN modules is very different from the code I write when doing maintenance on a contract. In the first case, the only people I expect to even read it are programmers of my skill level, so I can use more advanced constructs (soft references and closures) and my code can be more compact. I also make extensive use of direct access into @_, where I would never do that in application code.
      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?
[reply]

In Section Meditations