"... really cannot be used anywhere other than within the website that it is written for - really...it cannot ..."

Unfortunately, what happens all too often, is a sequence like this:

  1. You write something specifically for "A" (whatever that might be). The code is peppered with hard-coded "A"s throughout.
  2. At some later point you have a similar requirement for "B". You take a copy of the first code and replace all of the "A"s with "B"s. You add some enhancements to this version of the code.
  3. Further down the track, you have another similar requirement, this time for "C". You take a copy of the first code and replace all of the "A"s with "C"s. However, you notice that the enhancements which you added for the "B" code are not in the "C" code. You attempt to retrofit those enhancements but encounter problems. You scrap your new "C" code, take a copy of the "B" code and replace all of the "B"s with "C"s.
  4. And then something generic changes; it could be something minor like certain URLs with an http scheme now need an https scheme. You now sit down with your editor and modify the "A" code, then the "B" code, then the "C" code.
  5. Later you realise that the "A" code needs the enhancements that were originally added to the "B" code. You sit down again with your editor and ...

I hope you can see where this is going. There is no such thing as "will only be used by" or "final version" or anything else absolute like that. Every time you copy and substitute, or attempt to make identical changes in multiple files, you run the risk of introducing typos, subtle errors, and the like; the more you do this, these risks go from minimal chance to almost guaranteed. Furthermore, look at the huge rod you're making for your back with all of this extra work (that could've been avoided).

The A/B/C scenario I provided is, of course, a purely hypothetical example; however, it does mirror the type of thing that I've encountered on numerous occasions in over four decades of software development. Here's some examples.

Never assume your code will only ever be used by one entity. Always abstract your code such that it can be reused. Avoid hard-coded values like the plague.

Some of this might seem like additional work; however, once you get into the habit of doing it, you should find that it takes little or no extra effort. Moreover, as your software matures, the benfits accrue and you'll avoid the types of problems that I've indicated above.

You've been here for less than a year with a clear appetite for learning and improvement — this is great. You've taken onboard templates, placeholders, and so on; I hope you pick up on the ideas I've presented here too.

— Ken


In reply to Re^5: Debugging a module that's failing under taint mode by kcott
in thread Debugging a module that's failing under taint mode by Bod

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.