ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/common-sense/sense.pm
(Generate patch)

Comparing common-sense/sense.pm (file contents):
Revision 1.3 by root, Thu Jul 9 17:33:40 2009 UTC vs.
Revision 1.4 by root, Thu Jul 9 17:58:11 2009 UTC

18two typical (or not so typical - use your common sense) specimens of 18two typical (or not so typical - use your common sense) specimens of
19Perl coders. 19Perl coders.
20 20
21=over 4 21=over 4
22 22
23=item no warnings
24
25The dreaded warnings. Even worse, the horribly dreaded C<-w> switch. Even
26though we don't care if other people use warnings (and certainly there are
27useful ones), a lot of warnings simply go against the spirit of Perl, most
28prominently, the warnings related to C<undef>. There is nothing wrong with
29C<undef>: it has well-defined semantics, it is useful, and spitting out
30warnings you never asked for is just evil.
31
32So every module needs C<no warnings> to avoid somebody accidentally using
33C<-w> and forcing his bad standards on our code. No will do.
34
35Funnily enough, L<perllexwarn> explicitly mentions C<-w> (and not in a
36favourable way), but standard utilities, such as L<prove>, or MakeMaker
37when running C<make test> enable them blindly.
38
23=item use strict qw(subs vars) 39=item use strict qw(subs vars)
24 40
25Using C<use strict> is definitely common sense, but C<use strict 41Using C<use strict> is definitely common sense, but C<use strict
26'refs'> definitely overshoots it's usefulness. After almost two 42'refs'> definitely overshoots it's usefulness. After almost two
27decades of Perl hacking, we decided that it does more harm than being 43decades of Perl hacking, we decided that it does more harm than being
28useful. Specifically, constructs like these: 44useful. Specifically, constructs like these:
29 45
30 @{ $var->[0] } 46 @{ $var->[0] }
31 47
32Must be written like this, when C<use strict 'refs'> is in scope, and 48Must be written like this (or similarly), when C<use strict 'refs'> is in
33C<$var> can legally be C<undef>: 49scope, and C<$var> can legally be C<undef>:
34 50
35 @{ $var->[0] || [] } 51 @{ $var->[0] || [] }
36 52
37This is annoying, and doesn't shield against obvious mistakes such as 53This is annoying, and doesn't shield against obvious mistakes such as
38using C<"">, so one would even have to write: 54using C<"">, so one would even have to write:
53something breaks because it didn't anticipate future changes, so be 69something breaks because it didn't anticipate future changes, so be
54it. 5.10 broke almost all our XS modules and nobody cared either - and few 70it. 5.10 broke almost all our XS modules and nobody cared either - and few
55modules that are no longer maintained work with newer versions of Perl, 71modules that are no longer maintained work with newer versions of Perl,
56regardless of use feature. 72regardless of use feature.
57 73
58If your code isn'talive, it's dead, jim. 74If your code isn't alive, it's dead, jim.
59
60=item no warnings
61
62The dreaded warnings. Even worse, the horribly dreaded C<-w> switch. Even
63though we don't care if other people use warnings (and certainly there are
64useful ones), a lot of warnings simply go against the spirit of Perl, most
65prominently, the warnings related to C<undef>. There is nothing wrong with
66C<undef>: it has well-defined semantics, it is useful, and spitting out
67warnings you never asked for is just evil.
68
69So every module needs C<no warnings> to avoid somebody accidentally using
70C<-w> and forcing his bad standards on our code. No will do.
71
72(Also, why isn't this a C<use feature> switch? Adding warnings is
73apparently considered O.K., even if it breaks your programs).
74 75
75=item much less memory 76=item much less memory
76 77
77Just using all those pragmas together waste <blink>I<< B<776> kilobytes 78Just using all those pragmas together waste <blink>I<< B<776> kilobytes
78
79>></blink> of precious memory in my perl, for I<every single perl process 79>></blink> of precious memory in my perl, for I<every single perl process
80
81using our code>, which on our machines, is a lot. In comparison, this 80using our code>, which on our machines, is a lot. In comparison, this
82module only uses I<< B<four> >> kilobytes (I even had to write it out so 81module only uses I<< B<four> >> kilobytes (I even had to write it out so
83it looks like more) of memory on the same platform. 82it looks like more) of memory on the same platform.
84 83
85The money/time/effort/electricity invested in these gigabytes (probably 84The money/time/effort/electricity invested in these gigabytes (probably
103 $^H{feature_switch} = 102 $^H{feature_switch} =
104 $^H{feature_say} = 103 $^H{feature_say} =
105 $^H{feature_state} = 1; 104 $^H{feature_state} = 1;
106} 105}
107 106
108=cut
109
1101; 1071;
111 108
112=back 109=back
110
111=head1 NO 'no common::sense'
112
113This module doesn't offer an unimport. First of all, it wastes even more
114memory, second, and more importantly, who with even a bit of common sense
115would want no common sense?
113 116
114=head1 AUTHOR 117=head1 AUTHOR
115 118
116 Marc Lehmann <schmorp@schmorp.de> 119 Marc Lehmann <schmorp@schmorp.de>
117 http://home.schmorp.de/ 120 http://home.schmorp.de/
118 121
122 Robin Redeker, "<elmex at ta-sa.org>".
123
124
119=cut 125=cut
120 126

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines