… | |
… | |
9 | # roughly the same as, with much lower memory usage: |
9 | # roughly the same as, with much lower memory usage: |
10 | # |
10 | # |
11 | # use strict qw(vars subs); |
11 | # use strict qw(vars subs); |
12 | # use feature qw(say state switch); |
12 | # use feature qw(say state switch); |
13 | # no warnings; |
13 | # no warnings; |
|
|
14 | # use warnings qw(FATAL closed threads internal debugging pack substr malloc |
|
|
15 | # unopened portable prototype inplace io pipe unpack regexp |
|
|
16 | # deprecated exiting glob digit printf utf8 layer |
|
|
17 | # reserved parenthesis taint closure semicolon); |
|
|
18 | # no warnings qw(exec newline); |
14 | |
19 | |
15 | =head1 DESCRIPTION |
20 | =head1 DESCRIPTION |
16 | |
21 | |
17 | This module implements some sane defaults for Perl programs, as defined by |
22 | This module implements some sane defaults for Perl programs, as defined by |
18 | two typical (or not so typical - use your common sense) specimens of |
23 | two typical (or not so typical - use your common sense) specimens of Perl |
19 | Perl coders. |
24 | coders. |
20 | |
25 | |
21 | =over 4 |
26 | =over 4 |
22 | |
27 | |
23 | =item no warnings |
28 | =item use strict qw(subs vars) |
|
|
29 | |
|
|
30 | Using C<use strict> is definitely common sense, but C<use strict |
|
|
31 | 'refs'> definitely overshoots its usefulness. After almost two |
|
|
32 | decades of Perl hacking, we decided that it does more harm than being |
|
|
33 | useful. Specifically, constructs like these: |
|
|
34 | |
|
|
35 | @{ $var->[0] } |
|
|
36 | |
|
|
37 | Must be written like this (or similarly), when C<use strict 'refs'> is in |
|
|
38 | scope, and C<$var> can legally be C<undef>: |
|
|
39 | |
|
|
40 | @{ $var->[0] || [] } |
|
|
41 | |
|
|
42 | This is annoying, and doesn't shield against obvious mistakes such as |
|
|
43 | using C<"">, so one would even have to write (at least for the time |
|
|
44 | being): |
|
|
45 | |
|
|
46 | @{ defined $var->[0] ? $var->[0] : [] } |
|
|
47 | |
|
|
48 | ... which nobody with a bit of common sense would consider |
|
|
49 | writing. |
|
|
50 | |
|
|
51 | Curiously enough, sometimes perl is not so strict, as this works even with |
|
|
52 | C<use strict> in scope: |
|
|
53 | |
|
|
54 | for (@{ $var->[0] }) { ... |
|
|
55 | |
|
|
56 | If that isn't hypocrisy! And all that from a mere program! |
|
|
57 | |
|
|
58 | |
|
|
59 | =item use feature qw(say state given) |
|
|
60 | |
|
|
61 | We found it annoying that we always have to enable extra features. If |
|
|
62 | something breaks because it didn't anticipate future changes, so be |
|
|
63 | it. 5.10 broke almost all our XS modules and nobody cared either (or at |
|
|
64 | least I know of nobody who really complained about gratuitous changes - |
|
|
65 | as opposed to bugs). |
|
|
66 | |
|
|
67 | Few modules that are not actively maintained work with newer versions of |
|
|
68 | Perl, regardless of use feature or not, so a new major perl release means |
|
|
69 | changes to many modules - new keywords are just the tip of the iceberg. |
|
|
70 | |
|
|
71 | If your code isn't alive, it's dead, Jim - be an active maintainer. |
|
|
72 | |
|
|
73 | |
|
|
74 | =item no warnings, but a lot of new errors |
24 | |
75 | |
25 | Ah, the dreaded warnings. Even worse, the horribly dreaded C<-w> |
76 | Ah, the dreaded warnings. Even worse, the horribly dreaded C<-w> |
26 | switch: Even though we don't care if other people use warnings (and |
77 | switch: Even though we don't care if other people use warnings (and |
27 | certainly there are useful ones), a lot of warnings simply go against the |
78 | certainly there are useful ones), a lot of warnings simply go against the |
28 | spirit of Perl. |
79 | spirit of Perl. |
29 | |
80 | |
30 | Most prominently, the warnings related to C<undef>. There is nothing wrong |
81 | Most prominently, the warnings related to C<undef>. There is nothing wrong |
31 | with C<undef>: it has well-defined semantics, it is useful, and spitting |
82 | with C<undef>: it has well-defined semantics, it is useful, and spitting |
32 | out warnings you never asked for is just evil. |
83 | out warnings you never asked for is just evil. |
33 | |
84 | |
34 | So every module needs C<no warnings> to avoid somebody accidentally using |
85 | The result was that every one of our modules did C<no warnings> in the |
35 | C<-w> and forcing his bad standards on our code. No will do. Really, the |
86 | past, to avoid somebody accidentally using and forcing his bad standards |
36 | C<-w> switch should only enable wanrings for the main program. |
87 | on our code. Of course, this switched off all warnings, even the useful |
|
|
88 | ones. Not a good situation. Really, the C<-w> switch should only enable |
|
|
89 | warnings for the main program only. |
37 | |
90 | |
38 | Funnily enough, L<perllexwarn> explicitly mentions C<-w> (and not in a |
91 | Funnily enough, L<perllexwarn> explicitly mentions C<-w> (and not in a |
39 | favourable way), but standard utilities, such as L<prove>, or MakeMaker |
92 | favourable way, calling it outright "wrong"), but standard utilities, such |
40 | when running C<make test> enable them blindly. |
93 | as L<prove>, or MakeMaker when running C<make test>, still enable them |
|
|
94 | blindly. |
41 | |
95 | |
42 | =item use strict qw(subs vars) |
96 | For version 2 of common::sense, we finally sat down a few hours and went |
|
|
97 | through I<every single warning message>, identifiying - according to |
|
|
98 | common sense - all the useful ones. |
43 | |
99 | |
44 | Using C<use strict> is definitely common sense, but C<use strict |
100 | This resulted in the rather impressive list in the SYNOPSIS. When we |
45 | 'refs'> definitely overshoots its usefulness. After almost two |
101 | weren't sure, we didn't include the warning, so the list might grow in |
46 | decades of Perl hacking, we decided that it does more harm than being |
102 | the future (we might have made a mistake, too, so the list might shrink |
47 | useful. Specifically, constructs like these: |
103 | as well). |
48 | |
104 | |
49 | @{ $var->[0] } |
105 | Note the presence of C<FATAL> in the list: we do not think that the |
|
|
106 | conditions caught by these warnings are worthy of a warning, we I<insist> |
|
|
107 | that they are worthy of I<stopping> your program, I<instantly>. They are |
|
|
108 | I<bugs>! |
50 | |
109 | |
51 | Must be written like this (or similarly), when C<use strict 'refs'> is in |
110 | Therefore we consider C<common::sense> to be much stricter than C<use |
52 | scope, and C<$var> can legally be C<undef>: |
111 | warnings>, which is good if you are into strict things (we are not, |
|
|
112 | actually, but these things tend to be subjective). |
53 | |
113 | |
54 | @{ $var->[0] || [] } |
114 | After deciding on the list, we ran the module against all of our code that |
|
|
115 | uses C<common::sense> (that is almost all of our code), and found only one |
|
|
116 | occurence where one of them caused a problem: one of elmex's (unreleased) |
|
|
117 | modules contained: |
55 | |
118 | |
56 | This is annoying, and doesn't shield against obvious mistakes such as |
119 | $fmt =~ s/([^\s\[]*)\[( [^\]]* )\]/\x0$1\x1$2\x0/xgo; |
57 | using C<"">, so one would even have to write (at least for the time |
|
|
58 | being): |
|
|
59 | |
120 | |
60 | @{ defined $var->[0] ? $var->[0] : [] } |
121 | We quickly agreed that indeed the code should be changed, even though it |
|
|
122 | happened to do the right thing when the warning was switched off. |
61 | |
123 | |
62 | ... which nobody with a bit of common sense would consider |
|
|
63 | writing. |
|
|
64 | |
|
|
65 | Curiously enough, sometimes perl is not so strict, as this works even with |
|
|
66 | C<use strict> in scope: |
|
|
67 | |
|
|
68 | for (@{ $var->[0] }) { ... |
|
|
69 | |
|
|
70 | If that isn't hipocrasy! And all that from a mere program! |
|
|
71 | |
|
|
72 | =item use feature qw(say state given) |
|
|
73 | |
|
|
74 | We found it annoying that we always have to enable extra features. If |
|
|
75 | something breaks because it didn't anticipate future changes, so be |
|
|
76 | it. 5.10 broke almost all our XS modules and nobody cared either (or at |
|
|
77 | leats I know of nobody who really complained about gratitious changes - as |
|
|
78 | opposed to bugs). |
|
|
79 | |
|
|
80 | Few modules that are not actively maintained work with newer versions of |
|
|
81 | Perl, regardless of use feature or not, so a new major perl release means |
|
|
82 | changes to many modules - new keywords are just the tip of the iceberg. |
|
|
83 | |
|
|
84 | If your code isn't alive, it's dead, jim - be an active maintainer. |
|
|
85 | |
124 | |
86 | =item mucho reduced memory usage |
125 | =item mucho reduced memory usage |
87 | |
126 | |
88 | Just using all those pragmas mentioned in the SYNOPSIS together wastes |
127 | Just using all those pragmas mentioned in the SYNOPSIS together wastes |
89 | <blink>I<< B<776> kilobytes >></blink> of precious memory in my perl, for |
128 | <blink>I<< B<776> kilobytes >></blink> of precious memory in my perl, for |
… | |
… | |
100 | |
139 | |
101 | =cut |
140 | =cut |
102 | |
141 | |
103 | package common::sense; |
142 | package common::sense; |
104 | |
143 | |
105 | our $VERSION = '1.0'; |
144 | our $VERSION = '2.0'; |
|
|
145 | |
|
|
146 | # paste this into pelr to find bitmask |
|
|
147 | |
|
|
148 | # no warnings; |
|
|
149 | # use warnings qw(FATAL closed threads internal debugging pack substr malloc unopened portable prototype |
|
|
150 | # inplace io pipe unpack regexp deprecated exiting glob digit printf |
|
|
151 | # utf8 layer reserved parenthesis taint closure semicolon); |
|
|
152 | # no warnings qw(exec newline); |
|
|
153 | # BEGIN { warn join "", map "\\x$_", unpack "(H2)*", ${^WARNING_BITS}; exit 0 }; |
|
|
154 | |
|
|
155 | # overload should be included |
106 | |
156 | |
107 | sub import { |
157 | sub import { |
108 | # no warnings |
158 | # verified with perl 5.8.0, 5.10.0 |
109 | ${^WARNING_BITS} ^= ${^WARNING_BITS}; |
159 | ${^WARNING_BITS} = "\xfc\x3f\xf3\x00\x0f\xf3\xcf\xc0\xf3\xfc\x33\x03"; |
110 | |
160 | |
111 | # use strict vars subs |
161 | # use strict vars subs |
112 | $^H |= 0x00000600; |
162 | $^H |= 0x00000600; |
113 | |
163 | |
114 | # use feature |
164 | # use feature |
… | |
… | |
130 | =head1 STABILITY AND FUTURE VERSIONS |
180 | =head1 STABILITY AND FUTURE VERSIONS |
131 | |
181 | |
132 | Future versions might change just about everything in this module. We |
182 | Future versions might change just about everything in this module. We |
133 | might test our modules and upload new ones working with newer versions of |
183 | might test our modules and upload new ones working with newer versions of |
134 | this module, and leave you standing in the rain because we didn't tell |
184 | this module, and leave you standing in the rain because we didn't tell |
135 | you. |
185 | you. In fact, we did so when switching from 1.0 to 2.0, which enabled gobs |
|
|
186 | of warnings, and made them FATAL on top. |
136 | |
187 | |
137 | Most likely, we will pick a few useful warnings, instead of just disabling |
|
|
138 | all of them. And maybe we will load some nifty modules that try to emulate |
188 | Maybe we will load some nifty modules that try to emulate C<say> or so |
139 | C<say> or so with perls older than 5.10 (this module, of course, should |
189 | with perls older than 5.10 (this module, of course, should work with older |
140 | work with older perl versions - supporting 5.8 for example is just common |
190 | perl versions - supporting 5.8 for example is just common sense at this |
141 | sense at this time. Maybe not in the future, but of course you can trust |
191 | time. Maybe not in the future, but of course you can trust our common |
142 | our common sense to be consistent with, uhm, our opinion). |
192 | sense to be consistent with, uhm, our opinion). |
143 | |
193 | |
144 | =head1 WHAT OTHER PEOPLE HAD TO SAY ABOUT THIS MODULE |
194 | =head1 WHAT OTHER PEOPLE HAD TO SAY ABOUT THIS MODULE |
145 | |
195 | |
146 | apeiron |
196 | apeiron |
147 | |
197 | |
… | |
… | |
149 | "I hope common::sense is a joke." |
199 | "I hope common::sense is a joke." |
150 | |
200 | |
151 | crab |
201 | crab |
152 | |
202 | |
153 | "i wonder how it would be if joerg schilling wrote perl modules." |
203 | "i wonder how it would be if joerg schilling wrote perl modules." |
|
|
204 | |
|
|
205 | Adam Kennedy |
|
|
206 | |
|
|
207 | "Very interesting, efficient, and potentially something I'd use all the time." |
|
|
208 | [...] |
|
|
209 | "So no common::sense for me, alas." |
154 | |
210 | |
155 | H.Merijn Brand |
211 | H.Merijn Brand |
156 | |
212 | |
157 | "Just one more reason to drop JSON::XS from my distribution list" |
213 | "Just one more reason to drop JSON::XS from my distribution list" |
158 | |
214 | |
… | |
… | |
191 | |
247 | |
192 | acme |
248 | acme |
193 | |
249 | |
194 | "THERE IS NO 'no common::sense'!!!! !!!! !!" |
250 | "THERE IS NO 'no common::sense'!!!! !!!! !!" |
195 | |
251 | |
|
|
252 | apeiron (meta-comment about us commenting^Wquoting his comment) |
|
|
253 | |
|
|
254 | How about quoting this: get a clue, you fucktarded amoeba. |
|
|
255 | |
196 | =head1 AUTHOR |
256 | =head1 AUTHOR |
197 | |
257 | |
198 | Marc Lehmann <schmorp@schmorp.de> |
258 | Marc Lehmann <schmorp@schmorp.de> |
199 | http://home.schmorp.de/ |
259 | http://home.schmorp.de/ |
200 | |
260 | |