It's pretty amazing that this is such a discussion point in this TMTOWTDI language (sorry broquaint, paraphrased your words there).. It's like some sort of religion, in fact in my case more so.. Some say 'you must' some 'you musn\'t', and me, I don't really give a *wotsit*. (In both cases ,)

Did that explain any better? Probably not.. So I'll stick with my 'I\'d rather debug myself and be better at coding for it, than let some pragma do it for me.' reason.. Pick one..

C.

The general consensus seems to be that without 'strict', you code badly. I don't agree. (And several people that have seen my code don't seem to either..)

Possibly I just dont like a compiler telling me how to code

The compiler does that whether you use strict, though! That's why this is not a valid Perl program:

Prin "hellol;

I'd rather debug myself and be better at coding for it

I think that's a rather shortsighted view and a rather lame excuse.

I expect good programmers not to waste their time wanking over manual tasks that the computer is much better at doing reliably. Do you refuse to write automated test suites because you want to demonstrate your mad debugging skills?

Maybe you never make any typos. Maybe you've never spent an hour searching for a problem that doesn't make any sense and finally realized that you wrote $customr when you meant $customer. Since you say, though:

most of my globals are probably unintentional..

I wonder why you wouldn't want something to catch your unintentional errors immediately.

I find it hard to believe that anyone who's written anything longer than Hello, world hasn't been bitten by those errors, and that's why I suggest that refusing to let the computer catch common mistakes is a waste of your time.

Now you're picking holes in my ability to express myself. What I meant of course was, that I don't like the strict pragma telling me I cant use globals, symrefs etc. And not the compiler shouldn't correct non-language constructs.

You're taking things a liiiiiitttle to extremes here, aren't you? I could counter with 'and if you took a programmer, that always used strict, warnings, etc. pp. and gave them a language without these helpers, something to debug, how well would you expect them to do, alongside someone that's always debugged more manually?' - But that'd just be silly.

I like automated tests suites (not written any myself yet though), I wouldn't refuse to. There are always new or unexpected bugs though, even in code that conforms to strict. (As I wrote below, even if the code in itself is perfect, it doesn't mean it does what it's supposed to.)

I make typos, I've spent hours searching for them (privately, and at work in languages which arent as clever as perl), note that 'name used only once', is a 'warnings' error, not one from strict..

That last quote doesn't say anywhere that I think of 'unintentional globals' as errors.

So let me waste my time.. Thats my perrogative, and it's my time, maybe I like wasting it? :)

C.

(I'm wondering if answering this is also wasting my time, I'm not trying to change anyones minds here..)

Well, I will certainly never be the one to suggest that you should use it. I was more interested if there was a technical, as opposed to personal/ideological reason why you chose not to. If your happy, or just happier, without, then that's both your prerogative and good enough for me. My own use of strict is religious, but definitely not Religious. And even if it were the latter, I would never try to 'convert' anyone to it -- there's nothing more annoying in my book:)

From my own perspective, I'm more than happy to allow the computer to take care of as many of the mundane tasks that are involved in programming (and the rest of life) as I can pursuade it to do. That's the essence of programming and computers for me, getting this extremely fast, always willing, supremely dilligent and never forgetful, but essentially dumb assistant to do the stuff that I get bored with. In fact, given the choice there are a whole heap of things that I think that my editor/perl/OS could do for me that they don't (yet).

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Hooray!

So I'll stick with my 'I\'d rather debug myself and be better at coding for it, than let some pragma do it for me.' reason.

Sorry but that doesn't really make much sense to me. Why wouldn't you want the compiler to help you out? You can still learn from it. Personally I'd rather do a perl -c myprog.pl and have the compiler complain instead of assuming everything is ok and finding a subtle bug later on.

-- vek --

I'm still a noob Perl guy, however warnings and strict seems to have improved my understanding of perl by swatting me on the hand with 'so called bad habits.' I have a couple questions for you and am interested on your points a view concerning beginning programmers...

Do you reccommend new perl programmers to use or not use strict and/or warnings? Why?

If you were in an interview for a job you really wanted and the interviewer asked if you use strict in your code what would you say?

Looking for enlightenment,
Belmonts

2 easyish questions..
1. Do *I*? As in, of my own accord? I don't come across that many new programmers that I can think of. I do tend to reccommend warnings, if people are having problems figuring out why their code won't run, because without them perl just tends to die or stop working without saying why. Though most of those are just as easily caught by testing return values of things, like open(). I'm pretty sure I've never reccommended anyone to use strict, unsprisingly, as I don't much myself. Why not? Well it doesn't occur to me as being a way to help them improve. (That's not to say it isn't, just not *my* way.)

2. Having never had an interview for a perl job, I haven't come across this one yet. Being like I am, I'd tell the truth. (And it would be silly to say 'yes of course, all the time', and then get questions about what it would point out in some piece of code, and not know.) I would hope that they would merit me on my coding style and the functionality of it, etc.

The last job interview I had led me to a 'try-out' day, where they gave me some small thingy to programm in VBA, and I'm pretty sure the result could have been robuster, with a lot more checks on input etc, but that wasnt the point, the point was could I take a spec, understand it, and produce some sort of working result. For the rest you need to learn how they work anyway..

Oh, and currently I maintain a 'programm' there, which I didn't write, and doesn't use either warnings or strict.. Even adding warnings gets a page or so of output.. But the darn thing works, perfectly (ok, 99% ,) at a lot of customer sites.. So.. (I would like to improve it, but, no time, the boss says.. )

C.

'I\'d rather debug myself and be better at coding for it, than let some pragma do it for me'

You remembered to backslash the single quote! You must be a master of minor details and you probably never make any typos or bugs. I wish all my coworkers were just like you!

Okay, but I have to do things in the real world. Have pity on me. :-)

"Then I had one too many programs crash from a typo in a variable in an if branch I hadn't tested, and saw the light." -- tilly

"All i know is every time ive turned strict on in my code . . ., ive found errors. and same for other peoples code . . ." -- demerphq

Trust me on this one. You only need to do two things to see the "light." Take a Perl program of more than a few hundred lines, maybe something that you have not touched for a year, and do this:

1. Add "use strict;"
2. Add "my" or "our" to the first time each variable is used. This will shut off most of those warnings that you are getting.

Did you try it? Did you find a couple of misspelled variable names? Are you suprised that you found any? If you didn't find any, now you are sure that the code is perfect.

The general consensus seems to be that without 'strict', you code badly. I don't agree.

Have you ever made a typo in your code? How can you be sure there are none?

most of my globals are probably unintentional

<rant>You'd feel more strongly about this after being forced to work on code that has only global variables, many of which are one letter long. And the code is broken into multiple files. Which all use package main. Thankfully Perl gives you a way to work around this with "my" and/or "local." But it's still bloody sick. Maybe you (not YOU, but the person who did it) know that $j is the filename for the currently selected input file, but nobody else knows that. . .</rant>

Ok, challenge accepted:

-rwxrwxr--    1 cvs      cvs        143437 Oct 20  2002 mappergui.perl
+,v
[download]

This thing has 3500 lines, as you can see by the size.

It took me around 5 minutes to correct all the 'Global symbol' errors, none of which I see as critical, in fact in a GUI app I'd expect the actual GUI itself to be globally accessible. (Which is why I just threw a 'my $Mapper;' in at the top to solve those. I found one, single, misspelled variable name, which didnt surprise me in the least.. (never said I was perfect, or that the thing runs (ran) perfectly.) (Result available, should you want to see it.) BTW: Anything older than that (another year), would be unfair, I've only been using perl that long..

That this now says my code is perfect, is laughable. Unless you just mean the conformity is, it most probably still doesn't work as intended, which would be my definition of perfect.

Yes, I make typos, and I fix them, doesn't everybody? Yes I've also spent hours sometimes looking for stupid ones, that would have probably been shown using strict. I never said it didn't *work*..

As to your rant, probably/possibly. But I haven't yet, so I guess I got lucky. At least, I have some that uses lots of globals in several files, luckily more or less sensibly named. Anyway, I was talking about my preferences for my code, not other peoples. :)

C.

The general consensus seems to be that without 'strict', you code badly. I don't agree.

No, I do not think it is the general consensus that with strict one codes badly. I think the general consensus is that with strict one can be sure that a certain class of errors is avoided. strict is the difference between careless and careful programming, not between bad and good code.