1sense(3) User Contributed Perl Documentation sense(3)
2
6 common::sense - save a tree AND a kitten, use common::sense!
7
9 use common::sense;
10 # supposed to be the same, with much lower memory usage, as:
12 #
13 # use utf8;
14 # use strict qw(vars subs);
15 # use feature qw(say state switch);
16 # no warnings;
17 # use warnings qw(FATAL closed threads internal debugging pack malloc
18 # portable prototype inplace io pipe unpack regexp
19 # deprecated glob digit printf layer
20 # reserved taint closure semicolon);
21 # no warnings qw(exec newline unopened);
22
24 aXXNothing is more fairly distributed than common sense: no one thinks
25 he needs more of it than he already has.aXX
26 aXX RenA~X Descartes
28 This module implements some sane defaults for Perl programs, as defined
30 by two typical (or not so typical - use your common sense) specimens of
31 Perl coders. In fact, after working out details on which warnings and
32 strict modes to enable and make fatal, we found that we (and our code
33 written so far, and others) fully agree on every option, even though we
34 never used warnings before, so it seems this module indeed reflects a
35 "common" sense among some long-time Perl coders.
36 The basic philosophy behind the choices made in common::sense can be
38 summarised as: "enforcing strict policies to catch as many bugs as
39 possible, while at the same time, not limiting the expressive power
40 available to the programmer".
41 Two typical examples of how this philosophy is applied in practise is
43 the handling of uninitialised and malloc warnings:
44 uninitialised
46 "undef" is a well-defined feature of perl, and enabling warnings
47 for using it rarely catches any bugs, but considerably limits you
48 in what you can do, so uninitialised warnings are disabled.
49 malloc
51 Freeing something twice on the C level is a serious bug, usually
52 causing memory corruption. It often leads to side effects much
53 later in the program and there are no advantages to not reporting
54 this, so malloc warnings are fatal by default.
55 What follows is a more thorough discussion of what this module does,
57 and why it does it, and what the advantages (and disadvantages) of this
58 approach are.
59
61 use utf8
62 While it's not common sense to write your programs in UTF-8, it's
63 quickly becoming the most common encoding, is the designated future
64 default encoding for perl sources, and the most convenient encoding
65 available (you can do really nice quoting tricks...). Experience
66 has shown that our programs were either all pure ascii or utf-8,
67 both of which will stay the same.
68 There are few drawbacks to enabling UTF-8 source code by default
70 (mainly some speed hits due to bugs in older versions of perl), so
71 this module enables UTF-8 source code encoding by default.
72 use strict qw(subs vars)
74 Using "use strict" is definitely common sense, but "use strict
75 'refs'" definitely overshoots its usefulness. After almost two
76 decades of Perl hacking, we decided that it does more harm than
77 being useful. Specifically, constructs like these:
78 @{ $var->[0] }
80 Must be written like this (or similarly), when "use strict 'refs'"
82 is in scope, and $var can legally be "undef":
83 @{ $var->[0] || [] }
85 This is annoying, and doesn't shield against obvious mistakes such
87 as using "", so one would even have to write (at least for the time
88 being):
89 @{ defined $var->[0] ? $var->[0] : [] }
91 ... which nobody with a bit of common sense would consider writing:
93 clear code is clearly something else.
94 Curiously enough, sometimes perl is not so strict, as this works
96 even with "use strict" in scope:
97 for (@{ $var->[0] }) { ...
99 If that isn't hypocrisy! And all that from a mere program!
101 use feature qw(say state given)
103 We found it annoying that we always have to enable extra features.
104 If something breaks because it didn't anticipate future changes, so
105 be it. 5.10 broke almost all our XS modules and nobody cared either
106 (or at least I know of nobody who really complained about
107 gratuitous changes - as opposed to bugs).
108 Few modules that are not actively maintained work with newer
110 versions of Perl, regardless of use feature or not, so a new major
111 perl release means changes to many modules - new keywords are just
112 the tip of the iceberg.
113 If your code isn't alive, it's dead, Jim - be an active maintainer.
115 But nobody forces you to use those extra features in modules meant
117 for older versions of perl - common::sense of course works there as
118 well. There is also an important other mode where having
119 additional features by default is useful: commandline hacks and
120 internal use scripts: See "much reduced typing", below.
121 no warnings, but a lot of new errors
123 Ah, the dreaded warnings. Even worse, the horribly dreaded "-w"
124 switch: Even though we don't care if other people use warnings (and
125 certainly there are useful ones), a lot of warnings simply go
126 against the spirit of Perl.
127 Most prominently, the warnings related to "undef". There is nothing
129 wrong with "undef": it has well-defined semantics, it is useful,
130 and spitting out warnings you never asked for is just evil.
131 The result was that every one of our modules did "no warnings" in
133 the past, to avoid somebody accidentally using and forcing his bad
134 standards on our code. Of course, this switched off all warnings,
135 even the useful ones. Not a good situation. Really, the "-w" switch
136 should only enable warnings for the main program only.
137 Funnily enough, perllexwarn explicitly mentions "-w" (and not in a
139 favourable way, calling it outright "wrong"), but standard
140 utilities, such as prove, or MakeMaker when running "make test",
141 still enable them blindly.
142 For version 2 of common::sense, we finally sat down a few hours and
144 went through every single warning message, identifiying - according
145 to common sense - all the useful ones.
146 This resulted in the rather impressive list in the SYNOPSIS. When
148 we weren't sure, we didn't include the warning, so the list might
149 grow in the future (we might have made a mistake, too, so the list
150 might shrink as well).
151 Note the presence of "FATAL" in the list: we do not think that the
153 conditions caught by these warnings are worthy of a warning, we
154 insist that they are worthy of stopping your program, instantly.
155 They are bugs!
156 Therefore we consider "common::sense" to be much stricter than "use
158 warnings", which is good if you are into strict things (we are not,
159 actually, but these things tend to be subjective).
160 After deciding on the list, we ran the module against all of our
162 code that uses "common::sense" (that is almost all of our code),
163 and found only one occurence where one of them caused a problem:
164 one of elmex's (unreleased) modules contained:
165 $fmt =~ s/([^\s\[]*)\[( [^\]]* )\]/\x0$1\x1$2\x0/xgo;
167 We quickly agreed that indeed the code should be changed, even
169 though it happened to do the right thing when the warning was
170 switched off.
171 much reduced typing
173 Especially with version 2.0 of common::sense, the amount of
174 boilerplate code you need to add to gte this policy is daunting.
175 Nobody would write this out in throwaway scripts, commandline hacks
176 or in quick internal-use scripts.
177 By using common::sense you get a defined set of policies (ours, but
179 maybe yours, too, if you accept them), and they are easy to apply
180 to your scripts: typing "use common::sense;" is even shorter than
181 "use warnings; use strict; use feature ...".
182 And you can immediately use the features of your installed perl,
184 which is more difficult in code you release, but not usually an
185 issue for internal-use code (downgrades of your production perl
186 should be rare, right?).
187 mucho reduced memory usage
189 Just using all those pragmas mentioned in the SYNOPSIS together
190 wastes <blink>776 kilobytes</blink> of precious memory in my perl,
191 for every single perl process using our code, which on our
192 machines, is a lot. In comparison, this module only uses four
193 kilobytes (I even had to write it out so it looks like more) of
194 memory on the same platform.
195 The money/time/effort/electricity invested in these gigabytes
197 (probably petabytes globally!) of wasted memory could easily save
198 42 trees, and a kitten!
199 Unfortunately, until everybods applies more common sense, there
201 will still often be modules that pull in the monster pragmas. But
202 one can hope...
203
205 This module doesn't offer an unimport. First of all, it wastes even
206 more memory, second, and more importantly, who with even a bit of
207 common sense would want no common sense?
208
210 Future versions might change just about everything in this module. We
211 might test our modules and upload new ones working with newer versions
212 of this module, and leave you standing in the rain because we didn't
213 tell you. In fact, we did so when switching from 1.0 to 2.0, which
214 enabled gobs of warnings, and made them FATAL on top.
215 Maybe we will load some nifty modules that try to emulate "say" or so
217 with perls older than 5.10 (this module, of course, should work with
218 older perl versions - supporting 5.8 for example is just common sense
219 at this time. Maybe not in the future, but of course you can trust our
220 common sense to be consistent with, uhm, our opinion).
221
223 apeiron
224 "... wow"
226 "I hope common::sense is a joke."
227 crab
229 "i wonder how it would be if joerg schilling wrote perl modules."
231 Adam Kennedy
233 "Very interesting, efficient, and potentially something I'd use all the time."
235 [...]
236 "So no common::sense for me, alas."
237 H.Merijn Brand
239 "Just one more reason to drop JSON::XS from my distribution list"
241 Pista Palo
243 "Something in short supply these days..."
245 Steffen Schwigon
247 "This module is quite for sure *not* just a repetition of all the other
249 'use strict, use warnings'-approaches, and it's also not the opposite.
250 [...] And for its chosen middle-way it's also not the worst name ever.
251 And everything is documented."
252 BKB
254 "[Deleted - thanks to Steffen Schwigon for pointing out this review was
256 in error.]"
257 Somni
259 "the arrogance of the guy"
261 "I swear he tacked somenoe else's name onto the module
262 just so he could use the royal 'we' in the documentation"
263 Anonymous Monk
265 "You just gotta love this thing, its got META.json!!!"
267 dngor
269 "Heh. '"<elmex at ta-sa.org>"' The quotes are semantic
271 distancing from that e-mail address."
272 Jerad Pierce
274 "Awful name (not a proper pragma), and the SYNOPSIS doesn't tell you
276 anything either. Nor is it clear what features have to do with "common
277 sense" or discipline."
278 acme
280 "THERE IS NO 'no common::sense'!!!! !!!! !!"
282 apeiron (meta-comment about us commenting^Wquoting his comment)
284 "How about quoting this: get a clue, you fucktarded amoeba."
286 quanth
288 "common sense is beautiful, json::xs is fast, Anyevent, EV are fast and
290 furious. I love mlehmannware ;)"
291 apeiron
293 "... it's mlehmann's view of what common sense is. His view of common
295 sense is certainly uncommon, insofar as anyone with a clue disagrees
296 with him."
297 apeiron (another meta-comment)
299 "apeiron wonders if his little informant is here to steal more quotes"
301 ew73
303 "... I never got past the SYNOPSIS before calling it shit."
305 [...]
306 How come no one ever quotes me. :("
307
309 Or frequently-come-up confusions.
310 Is this module meant to be serious?
312 Yes, we would have put it under the "Acme::" namespace otherwise.
313 But the manpage is written in a funny/stupid/... way?
315 This was meant to make it clear that our common sense is a
316 subjective thing and other people can use their own notions, taking
317 the steam out of anybody who might be offended (as some people are
318 always offended no matter what you do).
319 This was a failure.
321 But we hope the manpage still is somewhat entertaining even though
323 it explains boring rationale.
324 Why do you impose your conventions on my code?
326 For some reason people keep thinking that "common::sense" imposes
327 process-wide limits, even though the SYNOPSIS makes it clear that
328 it works like other similar modules - i.e. only within the scope
329 that "use"s them.
330 So, no, we don't - nobody is forced to use this module, and using a
332 module that relies on common::sense does not impose anything on
333 you.
334 Why do you think only your notion of common::sense is valid?
336 Well, we don't, and have clearly written this in the documentation
337 to every single release. We were just faster than anybody else
338 w.r.t. to grabbing the namespace.
339 But everybody knows that you have to use strict and use warnings, why
341 do you disable them?
342 Well, we don't do this either - we selectively disagree with the
343 usefulness of some warnings over others. This module is aimed at
344 experienced Perl programmers, not people migrating from other
345 languages who might be surprised about stuff such as "undef". On
346 the other hand, this does not exclude the usefulness of this module
347 for total newbies, due to its strictness in enforcing policy, while
348 at the same time not limiting the expresive power of perl.
349 This module is considerably more strict than the canonical "use
351 strict; use warnings", as it makes all its warnings fatal in
352 nature, so you can not get away with as many things as with the
353 canonical approach.
354 This was not implemented in version 1.0 because of the daunting
356 number of warning categories and the difficulty in getting exactly
357 the set of warnings you wish (i.e. look at the SYNOPSIS in how
358 complicated it is to get a specific set of warnings - it is not
359 reasonable to put this into every module, the maintenance effort
360 would be enourmous).
361 But many modules "use strict" or "use warnings", so the memory savings
363 do not apply?
364 I suddenly feel sad...
365 But yes, that's true. Fortunately "common::sense" still uses only a
367 miniscule amount of RAM.
368 But it adds another dependency to your modules!
370 It's a fact, yeah. But it's trivial to install, most popular
371 modules have many more dependencies and we consider dependencies a
372 good thing - it leads to better APIs, more thought about
373 interworking of modules and so on.
374 Why do you use JSON and not YAML for your META.yml?
376 This is not true - YAML supports a large subset of JSON, and this
377 subset is what META.yml is written in, so it would be correct to
378 say "the META.yml is written in a common subset of YAML and JSON".
379 The META.yml follows the YAML, JSON and META.yml specifications,
381 and is correctly parsed by CPAN, so if you have trouble with it,
382 the problem is likely on your side.
383 But! But!
385 Yeah, we know.
386
388 Marc Lehmann <schmorp@schmorp.de>
389 http://home.schmorp.de/
390 Robin Redeker, "<elmex at ta-sa.org>".
392perl v5.12.2 2010-12-18 sense(3)