in reply to Re: IYHO, what do you consider good code?
in thread IYHO, what do you consider good code?

I agree with most of this, and do my best to follow it in my own code. Lately, though, I have been softening up on the use strict dogma. It's a great idea for you and me, but it might make some more unusual constructions more difficult. Good testing support provides a lot of the same usefulness as strict, but without the compiler errors :-). If your code changes an assumption, then the tests that rely on that assumption will scream bloody murder.

So here is my slightly modified version of the first point:

Update: theorbtwo's qualifier made perfect sense to me. Can't imagine why I forgot it. Whatever, the qualifier is now applied :-)

Replies are listed 'Best First'.
Re: Re: Re: IYHO, what do you consider good code?
by DrHyde (Prior) on Jun 13, 2003 at 11:07 UTC
    I'd say always use strict and warnings. Only turn it off for the sections of code where you need to. If you do think that you need to, consider whether there's a better way of doing the job - there almost always is. You generally only need to turn them off when you're expecting something magical to happen or are doing something Just Plain Weird. Magic and Weirdness are hard to read and so hard to maintain. Even with sufficient comments, someone who has to maintain your code later might just have to rip it out and start again if you try to be too clever. And, as well as commenting the input and output of your subroutines, COMMENT YOUR ALGORITHMS. (added shouty bit later)
[reply]
Re: Re: Re: IYHO, what do you consider good code?
by theorbtwo (Prior) on Jun 13, 2003 at 07:09 UTC

    I could agree with that, if you put a ..."and comment on exactly why you don't". However, note that I specificly didn't say that every line of code must comply with every stricture and warning.

    Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

[reply]

      I find myself using strict less and less often but only in constrained circumstances. Small scripts, stub applications for CGI::Application, that sort of thing. If it fills half the screen its probably too long to write without strict. Maybe this just means a lot of my scripts are now less than half a page long, I'm not sure. I just know that it is occasionally easier to just throw caution to the wind. But then I am also very likely to make warnings fatal which for me is a stricter sort of strict - your code ends being *required* to operate on the data sanely or you fall over a fatal runtime error.

      Added text. I included an example of the sort of thing I'm thinking of. This could be written with strict but why bother? I also wrote Re: and another without strict or warnings. I added them on at the end just to keep the 'use strict'/warnings people happy.

      #!/usr/bin/perl -T
BEGIN { $root = '/users/greentechnologist.org'; }
use lib $root;
use Camp;
Camp::DataEntry
    ->new( TMPL_PATH => "$root/Tmpl/",
           PARAMS => { DBH_DSN => 'dbi:Pg:dbname=...',
                       DBH_USER => '...',
                       DBH_PASS => '...',
                       DBH_OPT  => { RaiseError => 1 } } )
    ->run;

      [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom