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. | [reply] |