Perlmonk's "best pratices" in the real world

[schweini]

This is going to hurt...
<UPDATE>
It IS hurting (XP-wise). Let me just make clear that i am NOT advocating overall coding-anarchy, and that all of us should be using gotos everywhere - i'm simply asking how much personal, completly irrational "style" is possible without compromising too much efficiency.
</UPDATE>


Let me start off by stating that i am not using strict.
Let me add that i'm usually dont use warnings.

There, now that i have your attention, I'd like to get something off my mind that has been troubling me for a while now:
How important are all of the standard coding-rules that get mentioned in just about every thread here? (use CGI.pm! use strict! use warnings! use placeholders! use OO! use templates! use CGI::Application!). I know that each and every single one of these dogmas has its very good reasons, can boost efficiency, improve maintainability, lets you get 'run over by a bus' without anybody caring too much, make you more lazy, increase your hubris and presumably even lower your cholestorol.
But i've been hanging around with a couple of Basis (tm) BBX (tm) programmers these days (for those that don't know: thats a rather nasty BASIC-dialect, IMHO), and i even managed not to go blind looking at their (even for BASIC standards) horrible code. they didn't know anything about SQL, subroutines, code-refactorisation, beauty of code, assembler, registers, memory-usage, operating systems, OOP, etc.
But their code still works. and it works well.
My point being: i'm somewhere in-between. i know about all those 'higher concepts', but i often don't use them, either because i can really live without them (strict), "don't feel like it" (templates), consider myself incompatible with the concepts (OOP) or simply have too much mental inertia (CGI::App).
This obviously leads to suboptimal, yet (and not in the sense of 'a dirty hack') working code. I just wanted to ask whether i'm alone out here, because i'm really starting to feel intimidated around here lately - the whole meta-TIMTOWTDI-thing kinda seems to have taken the back seat, and this whole compsci/javaesque (no offense! {at all}) mentality seems to be very en vogue, and i'd bet that that scares off a lot of perl-coders that are slightly under my level, since it obviously takes a while to understand all those recommendations, and to appreciate them, and because they usually kill that BASICesque 'look, ma! my program is asking me for my name! tomorrow i'll program strong AI!' feeling that coding-toddlers love (and need) so much.
and in the real world (at least in the technological backwaters i'm swimming around in), it seems quite possible to survive (albeit not excel) without strictly following all those rules.
so:
am i alone, and simply one of few lousy, undisciplined coders, or is perlmonks (as much as i love it!) a bit too perfectionistic at times??

[sauoq]

Uhm... use strict; and use warnings;... at least while developing. They will help you catch stupid bugs quicker, leaving you more time to write code or play games.

With everything else you mention, the answer is an old standby: it depends.

I've written many CGI programs without CGI.pm or an alternative like CGI::Simple but most of them have something in common: no user input. Or very simple user input like, say, a path component but no parameters. If I'm processing parameters, I'll use a module that has that has tested code to do it. I've never used CGI::Application.

Sometimes OOP makes sense and sometimes it doesn't. If you aren't comfortable with it and don't care to be, then it doesn't make sense. Simple as that. There's nothing you can do with OOP that you can't do without it, so don't fret over it. Use what you know.

As for templates, if you haven't found a place where you need them yet it's probably because you really haven't needed them. You'll know when you do. Same thing with placeholders. You'll start using them when something breaks because you didn't.

Sometimes you have to look past the specific suggestions to find the more general advice. Often that advice boils down to "don't do work you don't need to" or "don't shoot yourself in the foot." No one can really tell you what is best in your situation.

In the end, most of these are really issues of style. The details matter very little. There are as many ways to write code well as there are good coders. The fundamentals like consistent formatting, appropriate commenting, and rigorous testing are far more important than which of the many MTOWTDI that you choose.

But, you really should use strict; and use warnings;... :-)

[skx]

I know this is being pedantic, but I find that using strict after development is over and when code is "live" is usually the most useful.

Sure it's nice to have in development, but as much testing as I can do it's when stuff is live that I really want to see comprehensive, readable, error messages.

[sauoq]

I know this is being pedantic,

No, it isn't. It's merely being opinionated. This reply is pedantic...

According to Merriam-Webster, an appropriate definition of "pedantic" in this usage would be "of, relating to, or being a pedant." Its root is defined variously as one who makes a show of knowledge, one who is unimaginative or who unduly emphasizes minutiae in the presentation or use of knowledge, or a formalist or precisionist in teaching.

I find that using strict after development is over and when code is "live" is usually the most useful.

Most of the errors that strict provides are compile time errors. The exception is a runtime error when you use symbolic reference under strict 'refs'. So, unless you have evals (the expression form) or are using /ee on regexes and propogating the errors in $@, strict is limited in its usefulness in "live" code.

That doesn't mean I don't leave it on; I generally do. But its benefits are definitely more pronounced during development. Besides, if your "live" code is generating errors because of strict checking, then development isn't exactly "over", now is it?

Sure it's nice to have in development, but as much testing as I can do it's when stuff is live that I really want to see comprehensive, readable, error messages.

Using strict doesn't change the quality of the error messages you get. Perhaps you are thinking about use diagnostics? Strict checking causes more conditions (the ones you usually want to avoid) to be reported as errors in the first place. Enabling warnings does exactly the same thing but results in warnings rather than errors.

BTW, if you aren't testing before the code is "live", then you are testing while it is live. Maybe what you are really saying is that you find these pragmas most useful during testing...

[jpfarmer]

As far as use warnings; goes, I normally remove it from non-critical production code that I don't actively use. I'll leave use strict; in forever, but I remove use warnings; because it can cause warning messages to pop up in perfectly valid code when versions of Perl change (and definations of what is warnable change with it). It makes users nervous, and normally doesn't affect much.

I picked this practice up from Learning Perl, 3rd ed. The passage I took it from:

"Of course, warnings are generally meant for programmers, not for end-users. If the warning won't be seen by a programmer, it probably won't do any good. And warnings won't change the behavior of your program, except that now it will emit gripes once in a while. If you get a warning message you don't understand, look for its explanation in the perldiag manpage.

Warnings change from one version of Perl to the next. This may mean that your well-tuned program runs silently when warnings are on today, but not when it's used with a newer (or older) version of Perl. ... But you shouldn't count on the text or behavior of any warning staying exactly the same in future Perl releases. "

[pg]

But their code still works. and it works well.

Yes. But they probably took twice the time a disciplined guy takes.

Yes. But later when an unlucky guy takes over those code, you will hear him swear all the time.

Yes. But one day, someone will say that he would rather rewrite it than fix all those bugs.

[schweini]

someone will say that he would rather rewrite it than fix all those bugs.
which is exactly what i have been doing :)

and as i tried to aknowledge: it IS suboptimal not to use every trick in the book, and i sure as hell am not advocating really sloppy programming practices, but how much sloppyness is acceptable, on the long run?

[IlyaM]

but how much sloppyness is acceptable, on the long run?

In long run no sloppyness is acceptable at all. Quick dirty solutions work only in short time. If the solution is to stay then for your own sanity rewrite/refactor it so it has no sloppyness you know about left. I learned this lesson hard way - not doing so hit myself so many times. If you allow yourself not to cleanup and refactor your code continuously you always end up with Big Ball of Mud which costs (in terms of time/money) way more to maintain.

[perrin]

I'm a little bit on the fence about what to tell you, since I've made good money as a consultant fixing other people's broken Perl code. What was broken about it? It was impossible to change or debug because it was written in the quick-hack style you are describing. Eventually, some managers would get fed up with the difficulty they were having making changes or fixing problems. Then they either hire someone like me to fix it, or declare that everything is going to Java.

There's the rub: you know how people who don't like Perl are always bitching about how they can't read it? This is why. And the more people write crappy Perl code, the more it reinforces the notion that Perl is only good for writing crappy code.

Why do we recommend solutions involving strict, templates, tests, etc. to people on Perlmonks? Because we tried them, and they worked really well. Becausse unlike my consulting gigs, no one pays me to answer questions on Perlmonks, and I get tired of helping people with something that would have been instantly obvious if they had used strict.

On the whole, I think that reminding people of what has been shown to work is a positive thing. I might choose to extract data from HTML with a regex, but it doesn't hurt anything for me to know that many people think a parser is the best way to do it. It might even help.

[mpeppler]

This pretty much sumarizes my take on this issue as well: perrin++

Michael

[Corion]

I see all these "best practices" like riding a motorbike with a helmet. Of course riding also is fun without a helmet, as long as I don't crash, but the helmet isn't there for the driving but for when a driver dosen't see me or when I miss a curve. Wearing a helmet is distracting, but if I'm going on any trip longer than 5 minutes, I'm gonna wear one. And also, it's the law to carry a helmet with you while riding a motorbike...

[talexb]

[cchampion]

According to to strict or not to strict, you're not alone, but it seems that the majority of the Monastery is against your view.

On a personal note, I started using strict and warnings long before joining the Monastery, and I haven't yet found a reason to do differently.

It is a mantra and it looks like that, but there are a few very good reasons for keeping chanting it. Strict and warnings are good help when you write programs, and they are invaluable when you need to find a bug.

[chromatic]

When you ask a code question on Perl Monks, there's a very real possibility you'll get an answer from someone who has:

• worked on the Perl core
• written a book or an article on the subject
• programmed professionally for more than ten years
• written the code being recommended
• solved the same problem multiple times
• made — and learned from — the same mistakes

Why ask smart people for advice just to ignore it?

[EvdB]

The larger a bit of code gets the more bugs there are - end of discussion. Most of the things you mention are ways of expanding the amount of code without increasing the bug count too much. For example CGI::Application is a very small module with almost no functionality that could not be created in a normal script. However it is a standard and well tested start - that is why it gets used. It puts you further along the 'make it work' road with less potential bugs.

I get paid to code. My customers don't pay for lines of code, or code beauty. They pay for it to work, to continue working and then not to break. They are paying for the absense of bugs. The things above - use warnings, use strict etc - help make this possible.

This means that I code simple routines and test them. The code looks and is simple - that way I can run through it in my head and check that it is correct. Then I apply buckets of tests to them.

I think the analogy that fits here is that of a professional football player versus an amateur. The professional footballer is paid to score. They ALWAYS warm up, wear pads, watch their diet. Amateurs play for fun - warm ups are less fun and the pulled muscles will heal in time.

So in summary I'm not sure I agree... I too throw out all the 'best practises' from time to time because they do slow down development. BUT I only do this for small bits of code and they are almost always one offs / one liners - see reply to reply below.

update: changed the first (now last) paragraph to reflect the rest of this post.

update 2: moved the first paragraph to the end - not sure if people were reading beyond it...

[cchampion]

I too throw out all the 'best practises' from time to time because they do slow down development

I fail to see how strict and warnings could slow down your development. I would say it's quite the opposite. Without strict and warnings it takes longer to realize where the mistakes lie, thus increasing your development time.

[EvdB]

I mean this in very limited circumstances such as:

perl -e '$a = "abcde"; print ($a =~ m/a.c/ ? "hit" : "miss");';

If it ever goes into a file then use strict, use warnings is ALWAYS there at the top. ALWAYS.

[LTjake]

When i started with perl, I was doing some CGI scripts using some sort of "readform" sub that tried to parse CGI params itself.

Eventually I found out that i could write "use CGI;" and it would do it all FOR me. That was pretty amazing to me. No more cutting and pasting of that half-asses sub.

Around the same time I learned about strict and warnings. What's this? Write two lines and it will find (some) problems with my script FOR me? Sweeet.

Generally, all of my programs looked something like this:

my $action = $cgi->param( 'action' );

if( $action eq 'show' ) {
# ...
}
elsif( $action eq 'delete' ) {
# ...
}
else {
# ...
}

After joining perlmonks, i found out about CGI::Application. It handles all of that messy if-elsif-else crap FOR me! At the same time, using HTML::Template allowed me to get rid of all of those pesky print q(...); and print << EOHEADER; statements and let my script focus on the data rather than the output.

Generally, my post can be summed up into: be lazy.

It really pays off. You get code re-use thus you have to write LESS code. Fewer, if any, cut & paste errors. Generally these modules are more robust and feature-rich than your code (because the module focusses on one single task).

Sure, no one is FORCING you to use these modules. You're welcome to write your own readform() sub as much as the next person. But... Why would you WANT to?

[hardburn]

But their code still works. and it works well.

Deifine "work". There's "work" as in "it runs, and covers the general case", and then there is "its robust, and will either handle edge cases without bugs, or will at least immediately stop when it detects one". A house of cards can stand a long time, as long as you don't have any sudden gusts of air or vibrations.

As for your "must-have" list:

use CGI.pm!

It's param() and header() methods are absolutely cruicial. There are so many edge cases in handling those two things that you're a fool if you try to do it on your own. You should either use CGI.pm or one of the other modules that replicate its functionality.

It's other methods (like HTML generation) are more debatable.

use strict! use warnings!

The only time I've really needed to shut off strict is the refs portion, and only for a tight lexical block. Most of the one-liners I write don't have strict, though I often end up typing my before variable names anyway, just out of habit.

I think I've only shut off warnings once, on a CGI in production that had been otherwise been working fine for months, but was spewing warnings in the error log. Again, it was only done for a single, tight lexical scope.

use placeholders!

Absolutely necessary. I have yet to see a single reason why they shouldn't be used. They are only slightly harder then interpolating the variable directly into the statement, they're infinately safer, and they're often more efficient (since the statement can be cached).

use OO!

Necessary far less then OO-purists would have you believe. OO isn't about reducing complexity, but keeping it managable. If your application is simple, then OO isn't really helping you.

It might be that a given module uses an OO-ish interface, simply because its convient to do so (though you can only call them 'OO' in the sense that they use blessed references or are called as class methods). Though I feel some modules currently using an OO-ish interface are better served with an Exporter-style (Email::Valid comes to mind).

use templates!

Should be used more often then not.

use CGI::Application!

CGI::Application is meant to be used when you have several form pages, each one feeding data from the last. I'd say if your CGI has three or fewer pages, then don't bother with CGI::Application. YMMV.

am i alone, and simply one of few lousy, undisciplined coders, or is perlmonks (as much as i love it!) a bit too perfectionistic at times??

My observation is that Perl Monks tends to be a bit different from many of the older sections of the overall Perl community. Many of Perl Monk's users (myself included) started Perl with Perl5 and a well-developed CPAN. The consequence is that many of the coding techniques used by those who have been around since Perl4 or earlier are considered bad form.

So yes, I do think Perl Monks tends further twards the more conservitive coding standards of compsci then most of the Perl community, though it is still part of the Perl community and will always be more liberal coders then Java. I see this as more of a good balance point then being 'too perfectionistic'.

[schweini]

That BBX-code i mentioned works in the sense of being 'functional' - i.e. does what it's supposed to do, but impossible to expand. actually, for the last year, i've been replacing all of it with my perl-code, and this meditation was in part inspired by the fear that ina couple of years, some poor schmuck will have to look at my code the same dazzled way i've been looking at that BBX stuff.

re: CGI.pm
i've always used it in the 'old school' way of getting my params (via Vars()) with it, and then basically forgetting about it. i prefer using my own header-generators and HTML-printing subs.
re: strict/warning
i frankly tried it a couple of times, but got annoyed by the a bit over-pedantic messages makeing a big fuss about nothing too serious. but iread about 'no strict vars' somewhere, so i'll give that a shot...
re: placeholders
i've actually been advocating placeholders on the DBI-list and here (i think) a couple of times, because i am so in love with them (you can't imagine the effect that BBX code had on my mental health)
re: OO
agreed - i think OO is cool for complex modules (DBI, Tk, etc.), where inheritance and friends actually make sense - but my apps that simply use all that funcionality tend to be a lot cleaner without OO...
re: templates
for 'normal' websites i guess i'd agree, but right now i'm working on this intranet-thing, and since basically all content is generated by my html-creator-subs, and formatted on the fly according to the data, i doubt that they would help me a lot right now..
re: CGI::App
I still don't get that one..i use the good ol' if ($in{action} eq "foo") style, and simply refuse to believe that using subs instead of conditionals make that much of a difference...
re: PM-style
very cool theory why perlmonks code they way they seem to!

[hardburn]

. . . this meditation was in part inspired by the fear that ina couple of years, some poor schmuck will have to look at my code the same dazzled way i've been looking at that BBX stuff.

Heh, I often wonder the same thing about my code. Often, I end up being that poor schmuck and end up cursing myself. Actually, I consider this a good thing--it means I learned something between then and now.

i've always used it in the 'old school' way of getting my params (via Vars()) with it

Nothing wrong with Vars()--it's just param() in disguise :) As long as you're not doing it by hand, you're OK.

i prefer using my own header-generators and HTML-printing subs.

Note that even in simple cases (outputing HTML, no cookies, etc.), CGI has already avoided problems for you:

$ perl -e 'use CGI qw(:standard); print header();'
Content-Type: text/html; charset=ISO-8859-1

Notice the addition of charset. I don't remember the specifics, but that avoids a potential cross-site scripting vulnerability.

Every time I thought I knew how to do CGIs safely, I find out about a new edge case that was already handled by CGI.pm, such as the above. Which is why I stick to it or one of its alternate cousins.

As for HTML creator subs, I think the case would be much stronger for them if Perl lacked a good templating system. As it happens, Perl has a lot of good templating systems (too many, some might say). Even if your project doesn't have an HTML specialist, I find templates are often easier to work with than mucking with code.

i frankly tried it a couple of times, but got annoyed by the a bit over-pedantic messages makeing a big fuss about nothing too serious.

Other then strict 'refs' (and only in very specific situations, like automatic generation of accsessors/mutators with closures), I've never seen strict give an error that wasn't serious. Maybe the code appeared to work, but it could have caused problems that would only be caught once it hit production.

As I noted, warnings is occasionally bothersome, but usually the same rules apply as for strict.

I still don't get that one..i use the good ol' if ($in{action} eq "foo") style, and simply refuse to believe that using subs instead of conditionals make that much of a difference...

I'm currently on a project that uses CGI::Application that as of this posting has 65 run modes, and will probably get a few more before it's done. The dispatch table that CGI::Application means that each run mode is called in O(1) time, instead of O(n) worst-case as it would be with a conditional tree. So it's more efficient, if nothing else.

Further, I keep all the run modes in a hash at the top of the applications, which is much easier to read then a huge conditional tree. Thanks to etags, my editor can jump directly to any run mode with two key strokes with the cursur over the desired mode in that hash (which is really nice, since this module is over 3000 lines long).

Lastly, CGI::Application has already done some things for me, such as loading HTML::Template files and doing the output to the browser.

One thing I don't like about it is that you can't write to the browser on your own, but have to return the complete output at the end of the sub. This is a major problem for one part of my application, where reports are generated from a database. The reports could get quite large--larger than I'd want to load into memory at once if I could avoid it.

[Anonymous Monk]

or is perlmonks (as much as i love it!) a bit too perfectionistic at times??

It's not about being perfectionistic, it's about being practical. Why should seekers of perl wisdom waste everyone's time on a piece of code which misteriously breaks but doesn't use strict or warnings? Wouldn't you find it embarresing to ask for help, have a monk examine your code and turn strict/warnings on and have the problem become apparent in under 10 seconds? Wouldn't you consider such a post a total waste of everyones time? I sure would

[ptkdb]

Blashphemy!!

Yet, is there a better way to liven things up around a monestary?

The question is, "would you 'use strict', even if no one told you to?"

The best 'Best Practices'(now that's getting painful) arise, NOT because they have become dogma, or are enforced by a bunch of anal control freaks but because THEY WORK.

Let's face it, some of us have 'worked without a net', left warnings and 'strict' off, telling ourselves, "we can get away with it, we 'cool', we 'good', we 'so well above average'. Only to have something end up in the code that takes us N hours to resolve that if we had used 'strict', warnings etc, would have been caught in a matter of minutes, if not seconds. And after a quick trip to local tatoo parlor to have 'use' put on the inside of one eyelid and 'strict' on the inside of the other, we never go without it again(almost never).

'use strict' isn't a best practice. It's a vaccination against hubris.

[ptkdb]

There once was a hot programmer named Mick.
He thought himself so hot, he didn't use strict
    one day the project had a bug
    everyone's stock options sunk.
And Mick's peers gave him a swift kick.

[AidanLee]

...and i'd bet that that scares off a lot of perl-coders that are slightly under my level, since it obviously takes a while to understand all those recommendations, and to appreciate them, and because they usually kill that BASICesque 'look, ma! my program is asking me for my name! tomorrow i'll program strong AI!' feeling that coding-toddlers love (and need) so much.

This is probably the single most important point of your post, as I see it. Although I'll confess to having been less than active with the PM community over the the last year or so, I know that myself and my fellow monks can certainly drown the uninitiated in well-meaning advice they aren't always ready for. And we don't even necessarily do it with an understanding tone. After you've posted the solution for the same problems a dozen times over, it can be easy to slip into a bit of indignation.

online developer communities tend to be rather DIY, sink or swim. They expect the petitioner to do as much legwork as they possibly can both before arriving with a question, and also in understanding the answers provided. While Perlmonks is quite good ad minimizing the latter, advanced programmers can often forget that there were two dozen steps between the question posed and the answer they give.

There also tends to be an awful lot of exposition (in the form of long-term collective experience) behind the mantras of 'use this', 'use that' which would be impractical to post more than once or twice. This is really where initiates need to do their homework. The answer to "why" can usually be answered much more thoroughly by the community's experiences (accessed through the handy search function) than by the monk who just answered your question.

I can't personally come to appoligize for the "do your homework" attitude, as I think it is a good one. Encouraging inquisitiveness is, IMHO, important to helping an initiate programmer to learn to fish, as the proverb goes. As perrin rightly points out, being a monk isn't a paid position.

I also think that handing our initiate their fishing pole and pointing them at the river needn't be accompanied by a kick in the butt to get them moving. Post Tone is a much debated topic in any forum, no less so here. It is ultimately up to the individual monk to decide how they formulate their posts. Hopefully the community as a whole will still be percieved as a welcoming place. I do believe that every monk answering questions wants to help the petitioner become the best programmer they can be.

[Coruscate]

I can't make up my mind when it comes to ++ing or --ing this node, so I'll leave it as a no-vote and be content with that method :) Now on to my comments:

How important are all of the standard coding-rules that get mentioned in just about every thread here?

They must be pretty important if nearly every thread mentions them. That just makes pure sense, does it not?

use CGI.pm!

CGI::Simple is also a great candidate, it's what I now use with all my CGI scripts. No more CGI.pm for me. If you are planning on accepting any user input or printing out http headers (I hope you do headers :P), one of the modules that have withstood the tests of time is a must.

use strict! use warnings!

I'm not sure what to say to this. Warnings and strict are a part of every single script I write, with the exception of shell one-liners. Not to use these pragmas just seems wrong to me.

use placeholders!

Placeholders are heavenly. Whenever database management is introduced into a project, placeholders become a necessity for me. I always use them, they save a lot of hassle!

use OO!

Nah. As already stated, OO is just for organization and for making hard work behind the scenes appear easy. OO is a wonderful tool with awesome powers, but it is not always needed to complete a good project.

use templates!

Templating systems are fantastic and should really be used within any major project. There are cases where using a templating system is overkill, so exceptions do exist. For the rest of the time, separating code from interface text makes for good programming practice. It looks neater, it's much better organized and the logic flows nicely.

use CGI::Application!

I admit to having never used this module. I just do it my own way, which is very concise and clear:

#!c:/perl/bin/perl -w
$|++;

use strict;
use CGI::Simple;

my $nodes = {
  index => \&main_index,
  links => \&show_links,
  shop  => \&shopping,
  _err  => \&invalid_node
};

my $node = $q->param('node') || 'index';
$nodes->{ exists $nodes->{$node} ? $node : '_err' }->();

sub main_index   { }
sub show_links   { }
sub shopping     { }
sub invalid_node { }

I know that each and every single one of these dogmas has its very good reasons, can boost efficiency, improve maintainability, lets you get 'run over by a bus' without anybody caring too much, make you more lazy, increase your hubris and presumably even lower your cholestorol.

Bravo, you just explained why yourself :)

[talexb]

[ellem]

[buzzcutbuddha]

I voted your comment up, not because I agree with what you said, but because you were willing to stand up and ask.

Part of becoming a master in anything involves questioning the 'best practices' that have been taught to you, and struggling with why others consider them best practices. It is only in your own eventual discovery of the truths held within those those best practices that you begin to find mastery.

This too, is true in Perl.

[duff]

I don't usually use strict, nor do I usuually use warnings. I don't need to because I've been coding forever and I can debug my own code rather quickly. Not to mention that more often than not warnings get in my way. That said, I get what I ask for. The burden rests solely on my shoulders to figure out what's wrong when things go wrong. Were I to use stricture and warnings, at least perl would be helping me discover where the problems lie. (Of course, when coding with others, stricture and warnings are on because there is always varying levels of skill in any group)

Now, do I recommend newbie perlers to use strict and warnings? Absolutely! But I also recommend that they understand what they mean and what they do. What usually happens though is that a newbie writes a one-liner with stricture and warnings enabled and doesn't understand why, just that a perl luminary told them they needed those things.

[Paulster2]

I beleive that there are two reasons people write sloppy code and get away with it: 1) They are lazy, 2) They don't want someone else to decipher what there writing, making it plainly (and painfully) theirs.

While I'm as lazy and the next person (read: male), I hate trying to decipher code that looks like something from the obfuscation page. This would be code that I have inherited for what ever reason. Let's face it, we are all expendible in the job market, so it is just as likely that you will move on to your next job and leave the poor slob who inherits your job a pile of muck, only to find out that the job you are going to has a bigger pile of muck to sift through. Not a good thing.
The other thing about writing usable but ugly code is that you will probably have to go back to it at some time. Then you realize that you don't have any idea what you have written. This is an even larger headache.

One other thing that I should mention about myself, I am a reformed anal-retentive. I'm just in the anal realm now. This probably explains a lot.

[schweini]

I'd just like to share a little observation here, which i found quite interesting:
up to now, i think i have been up- and downvoted at least 40 times (first time i see that the monks can't make up their minds). i thought that was quite interesting, taking the topic into account.
additionaly, i'd just really like to make it clear that my code isn't THAT bad...maybe not "PM-class", but certainly maintainable (even by someone else than me). but i am of course walways willing to improve...
but my original post wasn't supposed to me that much about me, but the perlmonks-attidude...but hey! i learned something.

[perrin]

You accidentally stumbled onto a very controversial issue. Perl has a diverse community, partly because it offers a better balance between "just get it done" and "do it right" than most other languages. There is bound to be some friction between these attitudes in any public place where people talk about Perl. I've seen it in person at most of the jobs I've had. As long as people treat each other politely and recognize that others may have something to teach us, it is usually not a big problem.

[jryan]

up to now, i think i have been up- and downvoted at least 40 times

Why do you care?

[schweini]

i dont!
well..not that much... :-)
i just wnated to say that i am a bit surprised about the activity on this thread, and how the ++ and the -- keep their balance...
and addionally, i have to admit that my ego's suffering a bit, because everybody seems to assume that i'm a complete newbie...really kinda hurts.

[revdiablo]

This is about the 5th post of yours which I have read, and I can't keep quiet any longer. I realize we are all not English professors, and the Monastery is not a literature course. But, if your code is anywhere near as bad as your Perlmonks posts, I wouldn't want to touch it with a 10 foot pole.

There are many types of errors present, but the easiest to fix are probably the numerous typos. It's really not that difficult to avoid this type of thing. Please, I beg of you, slow down! At least read your posts one or two times before submitting them. Or perhaps you are posting while drunk? That would explain a few things... ;)

[revdiablo slowly and carefully puts on his fire-retardant suit as he dismounts his high and mighty soapbox]