Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

Most of the code that I encounter was written by other people, many other people, over a long period of time.   Long enough that both the framework technologies and even [Perl | whatever] itself have evolved.   When you look at a code-base like that, you can watch the influence of various fads and fashions, as they come and go.   There have been just three things that I have most wanted to ask / beg of the coders who are writing “the crappy code of tomorrow” ;-), today:

(1) Write for the future, and be consistent with the past.   Sometimes it is much better to keep one way of doing something, in a large application, than to introduce another way of doing the same thing that (a) is no better, and (b) burdens other parts of the system ... especially, exception-handling code ... with decision-making therefore complexity that doesn’t bring added value.   For instance, use eval or Try::Tiny, but not both.   Don’t launch on a big project (especially an unauthorized one) to save the application from itself.   Some of the directives in Perl exercise a surprise influence upon how the language itself behaves, and this can be hugely disruptive, especially if their introduction by you into the project is, itself, a surprise.   Yes, we have the use languageversion; pragma, but there needs to be universal consensus before introducing any new code anywhere that would oblige one to use it.   An application consists not only of itself, but the entire and total context which surrounds it.   Undetected instability can come from anywhere.

(2) Don’t commit an “off-topic” change, or one that is any larger than it truly is required to be.   If, for example, you get annoyed that a piece of code is being Perl::Criticized, and you decide to Perl::Tidy it up to make it “–er,” you have just cut-off that entire piece of code from its history ... affecting every thread of changes in the version-control system that ever passed through that region of code.   (In every version-control system that has ever in the past been used ...)   It can even be very-disruptive for a piece of code to be visually different from the prevailing norm, even if some tool/pundit things that the new appearance is “–er.”   New ideas, which might be fantastic in a brand-new application (and how long has it been since you actually saw one of those ...?) can just be de-stabilizing.   There are no absolutes.   “There’s More Than One Way To Do It™” doesn’t mean that it is a good idea to introduce another way.   (In fact, please don’t.)

(3) Write for simplicity, and write tests for everything that you write.   Perl is not a strongly-typed language; the mere fact that a piece of source-code compiles does not tell you much of anything at all.   Many coders coming into the labor market today do not seem to be well-versed on this idea.   They are very dependent upon “compile-time” errors and warnings which Perl often simply does not have ... and, they are unaccustomed to seeing some of the very dynamic behaviors that are routinely used when writing (especially, legacy ...) Perl source-code.   If you do not have “test-driven development” in a Perl shop, maintaining stable releases can be very difficult ... especially among the work of the “new hands from foreign lands.”   The only way to know that something works, and that it did not break something else, is to continually prove it.

“Compatibility,” then, is not entirely a language feature:   it is a process feature.   It is an attribute, not so much of the language (whatever it is), but of the team’s own internal disciplines – and your own.

In reply to Re: Levels of strictness and compatibility by sundialsvc4
in thread Levels of strictness and compatibility by Anonymous Monk

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, 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, 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.
  • Log In?

    What's my password?
    Create A New User
    and all is quiet...

    How do I use this? | Other CB clients
    Other Users?
    Others scrutinizing the Monastery: (6)
    As of 2018-06-25 03:04 GMT
    Find Nodes?
      Voting Booth?
      Should cpanminus be part of the standard Perl release?

      Results (126 votes). Check out past polls.