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