… | |
… | |
4 | |
4 | |
5 | =head1 SYNOPSIS |
5 | =head1 SYNOPSIS |
6 | |
6 | |
7 | use common::sense; |
7 | use common::sense; |
8 | |
8 | |
9 | # roughly the same as, with much lower memory usage: |
9 | # supposed to be the same, with much lower memory usage, as: |
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 |
14 | # use warnings qw(FATAL closed threads internal debugging pack substr malloc |
15 | # unopened portable prototype inplace io pipe unpack regexp |
15 | # portable prototype inplace io pipe unpack regexp |
16 | # deprecated exiting redefine glob digit printf utf8 layer |
16 | # deprecated exiting glob digit printf utf8 layer |
17 | # reserved parenthesis taint closure semicolon); |
17 | # reserved parenthesis taint closure semicolon); |
18 | # no warnings qw(exec newline); |
18 | # no warnings qw(exec newline unopened); |
19 | |
19 | |
20 | =head1 DESCRIPTION |
20 | =head1 DESCRIPTION |
21 | |
21 | |
22 | 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 |
23 | 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 |
24 | Perl coders. |
24 | coders. In fact, after working out details on which warnings and strict |
|
|
25 | modes to enable and make fatal, we found that we (and our code written so |
|
|
26 | far, and others) fully agree on every option, even though we never used |
|
|
27 | warnings before, so it seems this module indeed reflects a "common" sense |
|
|
28 | among some long-time Perl coders. |
|
|
29 | |
|
|
30 | The basic philosophy behind the choices made in common::sense can be |
|
|
31 | summarised as: "enforcing strict policies to catch as many bugs as |
|
|
32 | possible, while at the same time, not limiting the expressive power |
|
|
33 | available to the programmer". |
|
|
34 | |
|
|
35 | Two typical examples of this philosophy are uninitialised and malloc |
|
|
36 | warnings: |
|
|
37 | |
|
|
38 | C<undef> is a well-defined feature of perl, and enabling warnings for |
|
|
39 | using it rarely catches any bugs, but considerably limits you in what you |
|
|
40 | can do, so uninitialised warnings are disabled. |
|
|
41 | |
|
|
42 | Freeing something twice on the C level is a serious bug, usually causing |
|
|
43 | memory corruption. It often leads to side effects much later in the |
|
|
44 | program and there are no advantages to not reporting this, so malloc |
|
|
45 | warnings are fatal by default. |
|
|
46 | |
|
|
47 | What follows is a more thorough discussion of what this module does, |
|
|
48 | and why it does it, and what the advantages (and disadvantages) of this |
|
|
49 | approach are. |
25 | |
50 | |
26 | =over 4 |
51 | =over 4 |
27 | |
52 | |
28 | =item use strict qw(subs vars) |
53 | =item use strict qw(subs vars) |
29 | |
54 | |
… | |
… | |
41 | |
66 | |
42 | This is annoying, and doesn't shield against obvious mistakes such as |
67 | 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 |
68 | using C<"">, so one would even have to write (at least for the time |
44 | being): |
69 | being): |
45 | |
70 | |
46 | @{ defined $var->[0] ? $var->[0] : [] } |
71 | @{ defined $var->[0] ? $var->[0] : [] } |
47 | |
72 | |
48 | ... which nobody with a bit of common sense would consider |
73 | ... which nobody with a bit of common sense would consider |
49 | writing. |
74 | writing: clear code is clearly something else. |
50 | |
75 | |
51 | Curiously enough, sometimes perl is not so strict, as this works even with |
76 | Curiously enough, sometimes perl is not so strict, as this works even with |
52 | C<use strict> in scope: |
77 | C<use strict> in scope: |
53 | |
78 | |
54 | for (@{ $var->[0] }) { ... |
79 | for (@{ $var->[0] }) { ... |
… | |
… | |
68 | Perl, regardless of use feature or not, so a new major perl release means |
93 | 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. |
94 | changes to many modules - new keywords are just the tip of the iceberg. |
70 | |
95 | |
71 | If your code isn't alive, it's dead, Jim - be an active maintainer. |
96 | If your code isn't alive, it's dead, Jim - be an active maintainer. |
72 | |
97 | |
|
|
98 | But nobody forces you to use those extra features in modules meant for |
|
|
99 | older versions of perl - common::sense of course works there as well. |
|
|
100 | There is also an important other mode where having additional features by |
|
|
101 | default is useful: commandline hacks and internal use scripts: See "much |
|
|
102 | reduced typing", below. |
73 | |
103 | |
|
|
104 | |
74 | =item no warnings, but a lot of new lexical errors |
105 | =item no warnings, but a lot of new errors |
75 | |
106 | |
76 | Ah, the dreaded warnings. Even worse, the horribly dreaded C<-w> |
107 | Ah, the dreaded warnings. Even worse, the horribly dreaded C<-w> |
77 | switch: Even though we don't care if other people use warnings (and |
108 | switch: Even though we don't care if other people use warnings (and |
78 | certainly there are useful ones), a lot of warnings simply go against the |
109 | certainly there are useful ones), a lot of warnings simply go against the |
79 | spirit of Perl. |
110 | spirit of Perl. |
80 | |
111 | |
81 | Most prominently, the warnings related to C<undef>. There is nothing wrong |
112 | Most prominently, the warnings related to C<undef>. There is nothing wrong |
82 | with C<undef>: it has well-defined semantics, it is useful, and spitting |
113 | with C<undef>: it has well-defined semantics, it is useful, and spitting |
83 | out warnings you never asked for is just evil. |
114 | out warnings you never asked for is just evil. |
84 | |
115 | |
85 | So every one of our modules did C<no warnings> in the past, to avoid |
116 | The result was that every one of our modules did C<no warnings> in the |
86 | somebody accidentally using and forcing his bad standards on our code. No |
117 | past, to avoid somebody accidentally using and forcing his bad standards |
87 | will do. Really, the C<-w> switch should only enable wanrings for the main |
118 | on our code. Of course, this switched off all warnings, even the useful |
88 | program only. |
119 | ones. Not a good situation. Really, the C<-w> switch should only enable |
|
|
120 | warnings for the main program only. |
89 | |
121 | |
90 | Funnily enough, L<perllexwarn> explicitly mentions C<-w> (and not in a |
122 | Funnily enough, L<perllexwarn> explicitly mentions C<-w> (and not in a |
91 | favourable way, calling it outright "wrong"), but standard utilities, such |
123 | favourable way, calling it outright "wrong"), but standard utilities, such |
92 | as L<prove>, or MakeMaker when running C<make test>, still enable them |
124 | as L<prove>, or MakeMaker when running C<make test>, still enable them |
93 | blindly. |
125 | blindly. |
94 | |
126 | |
95 | Anyways, since C<use warnings> is inacceptable, many people (including us |
127 | For version 2 of common::sense, we finally sat down a few hours and went |
96 | before we created common::sense) just flat out disabled all warnings. For |
128 | through I<every single warning message>, identifiying - according to |
97 | this module, we actually sat down a few hours and went through all the |
129 | common sense - all the useful ones. |
98 | warnings, and identified all the useful (accordign to common sense) |
|
|
99 | warnings. |
|
|
100 | |
130 | |
101 | This resulted in the rather impressive list in the SYNOPSIS. When we |
131 | This resulted in the rather impressive list in the SYNOPSIS. When we |
102 | weren't sure, we didn't include the warning, so the list might grow in |
132 | weren't sure, we didn't include the warning, so the list might grow in |
103 | the future (we might have made a mistake, too, so the list might shrink |
133 | the future (we might have made a mistake, too, so the list might shrink |
104 | again). |
134 | as well). |
105 | |
135 | |
106 | Note the presence of C<FATAL> in the list: we do not think that the |
136 | Note the presence of C<FATAL> in the list: we do not think that the |
107 | conditions caught by these warnings are worthy of a warning, we I<insist> |
137 | conditions caught by these warnings are worthy of a warning, we I<insist> |
108 | that they are worthy of stopping your program, instantly. They are bugs! |
138 | that they are worthy of I<stopping> your program, I<instantly>. They are |
|
|
139 | I<bugs>! |
109 | |
140 | |
110 | Therefore we consider C<common::sense> to be much stricter than C<use |
141 | Therefore we consider C<common::sense> to be much stricter than C<use |
111 | warnings>, which is good if you are into strict things (we are not, |
142 | warnings>, which is good if you are into strict things (we are not, |
112 | actually, but these things tend to be subjective). |
143 | actually, but these things tend to be subjective). |
113 | |
144 | |
… | |
… | |
118 | |
149 | |
119 | $fmt =~ s/([^\s\[]*)\[( [^\]]* )\]/\x0$1\x1$2\x0/xgo; |
150 | $fmt =~ s/([^\s\[]*)\[( [^\]]* )\]/\x0$1\x1$2\x0/xgo; |
120 | |
151 | |
121 | We quickly agreed that indeed the code should be changed, even though it |
152 | 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. |
153 | happened to do the right thing when the warning was switched off. |
|
|
154 | |
|
|
155 | |
|
|
156 | =item much reduced typing |
|
|
157 | |
|
|
158 | Especially with version 2.0 of common::sense, the amount of boilerplate |
|
|
159 | code you need to add to gte I<this> policy is daunting. Nobody would write |
|
|
160 | this out in throwaway scripts, commandline hacks or in quick internal-use |
|
|
161 | scripts. |
|
|
162 | |
|
|
163 | By using common::sense you get a defined set of policies (ours, but maybe |
|
|
164 | yours, too, if you accept them), and they are easy to apply to your |
|
|
165 | scripts: typing C<use common::sense;> is even shorter than C<use warnings; |
|
|
166 | use strict; use feature ...>. |
|
|
167 | |
|
|
168 | And you can immediately use the features of your installed perl, which |
|
|
169 | is more difficult in code you release, but not usually an issue for |
|
|
170 | internal-use code (downgrades of your production perl should be rare, |
|
|
171 | right?). |
123 | |
172 | |
124 | |
173 | |
125 | =item mucho reduced memory usage |
174 | =item mucho reduced memory usage |
126 | |
175 | |
127 | Just using all those pragmas mentioned in the SYNOPSIS together wastes |
176 | Just using all those pragmas mentioned in the SYNOPSIS together wastes |
… | |
… | |
139 | |
188 | |
140 | =cut |
189 | =cut |
141 | |
190 | |
142 | package common::sense; |
191 | package common::sense; |
143 | |
192 | |
144 | our $VERSION = '2.0'; |
193 | our $VERSION = '2.03'; |
145 | |
194 | |
146 | # paste this into pelr to find bitmask |
195 | # paste this into perl to find bitmask |
147 | |
196 | |
148 | # no warnings; |
197 | # no warnings; |
149 | # use warnings qw(FATAL closed threads internal debugging pack substr malloc unopened portable prototype |
198 | # use warnings qw(FATAL closed threads internal debugging pack substr malloc portable prototype |
150 | # inplace io pipe unpack regexp deprecated exiting redefine glob digit printf |
199 | # inplace io pipe unpack regexp deprecated exiting glob digit printf |
151 | # utf8 layer reserved parenthesis taint closure semicolon); |
200 | # utf8 layer reserved parenthesis taint closure semicolon); |
152 | # no warnings qw(exec newline); |
201 | # no warnings qw(exec newline unopened); |
153 | # BEGIN { warn join "", map "\\x$_", unpack "(H2)*", ${^WARNING_BITS}; exit 0 }; |
202 | # BEGIN { warn join "", map "\\x$_", unpack "(H2)*", ${^WARNING_BITS}; exit 0 }; |
154 | |
203 | |
155 | # overload should be included |
204 | # overload should be included |
156 | |
205 | |
157 | sub import { |
206 | sub import { |
158 | # verified with perl 5.8.0, 5.10.0 |
207 | # verified with perl 5.8.0, 5.10.0 |
159 | ${^WARNING_BITS} = "\xfc\x3f\xf3\x00\xcf\xf3\xcf\xc0\xf3\xfc\x33\x03"; |
208 | ${^WARNING_BITS} ^= ${^WARNING_BITS} ^ "\xfc\x3f\x33\x00\x0f\xf3\xcf\xc0\xf3\xfc\x33\x03"; |
160 | |
209 | |
161 | # use strict vars subs |
210 | # use strict vars subs |
162 | $^H |= 0x00000600; |
211 | $^H |= 0x00000600; |
163 | |
212 | |
164 | # use feature |
213 | # use feature |
… | |
… | |
200 | |
249 | |
201 | crab |
250 | crab |
202 | |
251 | |
203 | "i wonder how it would be if joerg schilling wrote perl modules." |
252 | "i wonder how it would be if joerg schilling wrote perl modules." |
204 | |
253 | |
|
|
254 | Adam Kennedy |
|
|
255 | |
|
|
256 | "Very interesting, efficient, and potentially something I'd use all the time." |
|
|
257 | [...] |
|
|
258 | "So no common::sense for me, alas." |
|
|
259 | |
205 | H.Merijn Brand |
260 | H.Merijn Brand |
206 | |
261 | |
207 | "Just one more reason to drop JSON::XS from my distribution list" |
262 | "Just one more reason to drop JSON::XS from my distribution list" |
208 | |
263 | |
209 | Pista Palo |
264 | Pista Palo |
… | |
… | |
226 | |
281 | |
227 | "the arrogance of the guy" |
282 | "the arrogance of the guy" |
228 | "I swear he tacked somenoe else's name onto the module |
283 | "I swear he tacked somenoe else's name onto the module |
229 | just so he could use the royal 'we' in the documentation" |
284 | just so he could use the royal 'we' in the documentation" |
230 | |
285 | |
|
|
286 | Anonymous Monk |
|
|
287 | |
|
|
288 | "You just gotta love this thing, its got META.json!!!" |
|
|
289 | |
231 | dngor |
290 | dngor |
232 | |
291 | |
233 | "Heh. '"<elmex at ta-sa.org>"' The quotes are semantic |
292 | "Heh. '"<elmex at ta-sa.org>"' The quotes are semantic |
234 | distancing from that e-mail address." |
293 | distancing from that e-mail address." |
235 | |
294 | |
… | |
… | |
243 | |
302 | |
244 | "THERE IS NO 'no common::sense'!!!! !!!! !!" |
303 | "THERE IS NO 'no common::sense'!!!! !!!! !!" |
245 | |
304 | |
246 | apeiron (meta-comment about us commenting^Wquoting his comment) |
305 | apeiron (meta-comment about us commenting^Wquoting his comment) |
247 | |
306 | |
248 | How about quoting this: get a clue, you fucktarded amoeba. |
307 | "How about quoting this: get a clue, you fucktarded amoeba." |
|
|
308 | |
|
|
309 | quanth |
|
|
310 | |
|
|
311 | "common sense is beautiful, json::xs is fast, Anyevent, EV are fast and |
|
|
312 | furious. I love mlehmannware ;)" |
|
|
313 | |
|
|
314 | =head1 FREQUQNTLY ASKED QUESTIONS |
|
|
315 | |
|
|
316 | Or frequently-come-up confusions. |
|
|
317 | |
|
|
318 | =over 4 |
|
|
319 | |
|
|
320 | =item Is this module meant to be serious? |
|
|
321 | |
|
|
322 | Yes, we would have put it under the C<Acme::> namespace otherwise. |
|
|
323 | |
|
|
324 | =item But the manpage is written in a funny/stupid/... way? |
|
|
325 | |
|
|
326 | This was meant to make it clear that our common sense is a subjective |
|
|
327 | thing and other people can use their own notions, taking the steam out |
|
|
328 | of anybody who might be offended (as some people are always offended no |
|
|
329 | matter what you do). |
|
|
330 | |
|
|
331 | This was a failure. |
|
|
332 | |
|
|
333 | But we hope the manpage still is somewhat entertaining even though it |
|
|
334 | explains boring rationale. |
|
|
335 | |
|
|
336 | =item Why do you impose your conventions on my code? |
|
|
337 | |
|
|
338 | For some reason people keep thinking that C<common::sense> imposes |
|
|
339 | process-wide limits, even though the SYNOPSIS makes it clear that it works |
|
|
340 | like other similar modules - only on the scope that uses them. |
|
|
341 | |
|
|
342 | So, no, we don't - nobody is forced to use this module, and using a module |
|
|
343 | that relies on common::sense does not impose anything on you. |
|
|
344 | |
|
|
345 | =item Why do you think only your notion of common::sense is valid? |
|
|
346 | |
|
|
347 | Well, we don't, and have clearly written this in the documentation to |
|
|
348 | every single release. We were just faster than anybody else w.r.t. to |
|
|
349 | grabbing the namespace. |
|
|
350 | |
|
|
351 | =item But everybody knows that you have to use strict and use warnings, |
|
|
352 | why do you disable them? |
|
|
353 | |
|
|
354 | Well, we don't do this either - we selectively disagree with the |
|
|
355 | usefulness of some warnings over others. This module is aimed at |
|
|
356 | experienced Perl programmers, not people migrating from other languages |
|
|
357 | who might be surprised about stuff such as C<undef>. On the other hand, |
|
|
358 | this does not exclude the usefulness of this module for total newbies, due |
|
|
359 | to its strictness in enforcing policy, while at the same time not limiting |
|
|
360 | the expresive power of perl. |
|
|
361 | |
|
|
362 | This module is considerably I<more> strict than the canonical C<use |
|
|
363 | strict; use warnings>, as it makes all its warnings fatal in nature, so |
|
|
364 | you can not get away with as many things as with the canonical approach. |
|
|
365 | |
|
|
366 | This was not implemented in version 1.0 because of the daunting number |
|
|
367 | of warning categories and the difficulty in getting exactly the set of |
|
|
368 | warnings you wish (i.e. look at the SYNOPSIS in how complicated it is to |
|
|
369 | get a specific set of warnings - it is not reasonable to put this into |
|
|
370 | every module, the maintainance effort would be enourmous). |
|
|
371 | |
|
|
372 | =item But many modules C<use strict> or C<use warnings>, so the memory |
|
|
373 | savings do not apply? |
|
|
374 | |
|
|
375 | I am suddenly so sad. |
|
|
376 | |
|
|
377 | But yes, that's true. Fortunately C<common::sense> still uses only a |
|
|
378 | miniscule amount of RAM. |
|
|
379 | |
|
|
380 | =item But it adds another dependency to your modules! |
|
|
381 | |
|
|
382 | It's a fact, yeah. But it's trivial to install, most popular modules have |
|
|
383 | many more dependencies and we consider dependencies a good thing - it |
|
|
384 | leads to better APIs, more thought about interworking of modules and so |
|
|
385 | on. |
|
|
386 | |
|
|
387 | =item Why do you use JSON and not YAML for your META.yml? |
|
|
388 | |
|
|
389 | This is not true - YAML supports a large subset of JSON, and this subset |
|
|
390 | is what META.yml is written in, so it would be correct to say "the |
|
|
391 | META.yml is written in a common subset of YAML and JSON". |
|
|
392 | |
|
|
393 | The META.yml follows the YAML, JSON and META.yml specifications, and is |
|
|
394 | correctly parsed by CPAN, so if you have trouble with it, the problem is |
|
|
395 | likely on your side. |
|
|
396 | |
|
|
397 | =item But! But! |
|
|
398 | |
|
|
399 | Yeah, we know. |
|
|
400 | |
|
|
401 | =back |
249 | |
402 | |
250 | =head1 AUTHOR |
403 | =head1 AUTHOR |
251 | |
404 | |
252 | Marc Lehmann <schmorp@schmorp.de> |
405 | Marc Lehmann <schmorp@schmorp.de> |
253 | http://home.schmorp.de/ |
406 | http://home.schmorp.de/ |