in reply to Re^7: Legacy Code: "Dominoes = Bad"
in thread Legacy Code: "Dominoes = Bad"

Could it be that monks of your experience will see almost any example as trivial, because it's something you've been doing for years?

If not, what about CGI.pm? Would you agree that using CGI.pm is less effort and more maintainable? I posit that this is a non-trivial example because it is so frequent (still!), particularly roll-your-own query-string parsing.

How about descriptive varible names? One might argue that typing $target_hostname is more physical effort than $th, but descriptive hostnames can reduce cognitive effort, and if you know your way around your editor, the physical difference can be minimal.



- Boldra

Replies are listed 'Best First'.
Re^9: Legacy Code: "Dominoes = Bad"
by JavaFan (Canon) on Apr 30, 2011 at 13:24 UTC
    Would you agree that using CGI.pm is less effort and more maintainable? I posit that this is a non-trivial example because it is so frequent (still!), particularly roll-your-own query-string parsing.
    Using CGI.pm or not is about code reuse, not maintainability. But say I had handrolled my own CGI parsing, and for whatever new requirement, I now have the need to separate arguments not only by '&' and ';', but also by '-'. What do you think would be easier to do, change the code I wrote myself, or code that someone else wrote, and which doesn't live in my source control, but instead is maintained by the system wide packaging system, as it's third party software? (Note that I almost always would use CGI.pm if the alternative was writing it myself, but not for maintainability reasons - because code reuse makes I can deliver faster).
    Could it be that monks of your experience will see almost any example as trivial, because it's something you've been doing for years
    There's a lot that's not trivial. But I do mean a real function (or module) that does something - not a fragment like variable names. I'm asking for two implementations of the same functionality: one written in the simplest way, doing nothing more than required, and one written in the maintainable way, and then to show the latter did not take more effort to write than the former. (And with more effort, I do not mean the number of characters - typing '$target_hostname' or '$th' takes the same effort - effort is much more than the physical act of depressing and releasing keys; thinking what to write is effort; testing your code is effort; merging it into existing code may be an effort, etc)
[reply]

      You would not use CGI.pm for maintainability reasons, but you would because its less work. Sounds like a good example to me...

      Using the example of a system of many non-trivial CGI's, implementing something such as CGI.pm for reuse across all of them is going to be more maintainable and less work than rolling your own unique, simplest-method parser for each.

      Your mention of 3rd party issues certainly makes the reuse issue more interesting, but copying/renaming CGI.pm into your repo and taking control is still more maintainable and less work than rolling your own a hundred times.

      Where I come from anything of interesting scale is done in teams, and teams of teams. So everything is some level of "3rd-party". That's not a justification for each of us to duplicate each others work. Learning someone else's code is work. Past the xth reuse however, and the nth bugfix, the learning work is less than the rolling-your-own-again work.

      Taken by itself, a single method, or single CGI might implement the simplest-possible option parser, and that's good. In fact you might have a hundred doing the same simplest thing, and that might also be good. Put them into the same system, and add the requirement that they should all exhibit similar usability behaviors. Then add a new style of behavior they must all adhere to such as your '-' example, and that's where simplest parsing method for each individual CGI becomes the nightmare to maintain system.

      --Dave

[reply]
        Using the example of a system of many non-trivial CGI's, implementing something such as CGI.pm for reuse across all of them is going to be more maintainable and less work than rolling your own unique, simplest-method parser for each.
        How so? You still haven't shown how CGI.pm is easier maintained than code I wrote myself.

        Or is your position that code written by someone else and put on CPAN (or made part of the Perl distribution) is immune to requirement changes, but any code I write myself is subject to changes in requirements? Because that's seems to be the assumption behind the "all code must be maintainable" - that all requirements change, and that code isn't static.

        Meanwhile, I'm still waiting for a piece of non-trivial code, written in a simple way, that would have taken less time to write if it was written in a "maintainable way".

[reply]

In Section Meditations