Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

comment on

( [id://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

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



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (2)
As of 2024-03-19 06:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found