The most important thing to comment are the assumptions you (the programmer) made. For example, "$var must not be undef.", "This algorithm is only ideal for lists no bigger than XXX elements.", "The module may not be thread-safe." and "Uses features specific to Win32."I understand that you were merely making stuff up off the cuff, but I think those are bad examples. Any assumptions should really be coded as assertions and the comments should explain why the check is there.
...etc.#sub foo() which sets $var can never fail for such and such reason defined($var) or die "\$var must not be undef.\n" #I'm too lazy to make it work properly for all lists (@list > $XXX) or warn "This algorithm is only ideal for lists no". " bigger than $XXX elements." #cross platform compatibility is comming in version 9.0 ($^O eq 'MSWin32') or die "Platform not supported"
In reply to Re^2: Meaning of Maintanability and Functionality in Coding Perl
by Anonymous Monk
in thread Meaning of Maintanability and Functionality in Coding Perl
by neversaint
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |