in reply to Re: What habits do you have to avoid introducing bugs?
in thread What habits do you have to avoid introducing bugs?

++

I did not have the -w on the #! line even though I did have use strict; . Good catch.

That said the warnings do report the mistake to STDERR but do not stop the program from running. In this case the fork bomb still happens.

Update: Also perl -w -c does not report this mistake.

Replies are listed 'Best First'.
Re^3: What habits do you have to avoid introducing bugs?
by Util (Priest) on Feb 06, 2008 at 06:37 UTC

    do not stop the program from running ... fork bomb still happens
    True!

    After futher consideration, I came up with many more habits, but few that are akin to the OP. I don't even like it (0 == $foo) myself; I use it in C, but am glad to not need it in Perl.
    More of my habits:

    • Strict and warnings, of course!
    • Write in a Syntax Highlighting editor.
    • Write at least one test ASAP, and run it frequently (roughly each time I hit Save).
    • If I can't write normal tests (maintenance on a huge web package), at least get (WWW::Mechanize) the complete output of one sample run, and compare against *that* as my test.
    • Align similar code, and write code that is alignable (until refactoring makes sense).
    • Prefer to write Table or Data-driven code where possible.
    • (Except when skipping out with next/last) Never write an if{}elsif{} without an else, even if it is just a documented '# Do nothing'.
    • (During early development) Die at the drop of a hat. Don't just die where you see possible errors; use assertions on *everything* that you can predict the state of. Die on "Can't happen"!
    • Make whitespace visible on diagnostic output: die "Foo '$foo' has an invalid value"; the single-quotes show me that $foo contains trailing whitespace.
    • I copy a template to create each new program. In its top block is this line, to foil non-printables and buffering issues that confound debugging. The whole line is either commented on uncommented together: #use Data::Dumper; $Data::Dumper::Useqq=1; $|=1;.
    • Examine the data during development, rather than waiting for debugging:
      # I want to write this: my @rows = @{ $dbh->selectall_arrayref($sql) }; # Instead, I always write this, and remove the dump # after verifying the data and its format: my $rows_aref = $dbh->selectall_arrayref($sql) or die; print Dumper $rows_aref; my @rows = @{$rows_aref};
      Hence I see early that each row is an arrayref (not the expected scalar), even though I only asked for one field in the select. 1 minute of checking my assumptions saved 15 minutes of later debugging.

Re^3: What habits do you have to avoid introducing bugs?
by lodin (Hermit) on Feb 06, 2008 at 17:32 UTC

    In this case the fork bomb still happens.

    Make it fatal:

    use warnings FATAL => 'all';

    lodin

Re^3: What habits do you have to avoid introducing bugs?
by DrHyde (Prior) on Feb 07, 2008 at 10:42 UTC
    -w -c doesn't catch it? Yes it does:

    $ perl -w -c -e 'if($status = 0) { $status = 1 }' Found = in conditional, should be == at -e line 1. -e syntax OK

    That's using 5.8.8, BTW.