Очевидно, вы забыли посчитать нулевую статью из первой главы. Классическая ошибка на +/- 1 :)<br><br><div class="gmail_quote">18 января 2012 г. 8:49 пользователь Иван Бессарабов <span dir="ltr"><<a href="mailto:ivan@bessarabov.ru">ivan@bessarabov.ru</a>></span> написал:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">На странице <a href="http://oreilly.com/perl/excerpts/perl-best-practices/appendix-b.html" target="_blank">http://oreilly.com/perl/excerpts/perl-best-practices/appendix-b.html</a><br>
сказано что в Perl Best Practices 256 статей: "This appendix lists the<br>
complete set of 256 guidelines presented in this book.". На этой же<br>
странице приведен список. Я их пересчитал и у меня получилось 255.<br>
Какую статью я пропустил?<br>
<br>
Chapter 2, [Code Layout]<br>
* 1 Brace and parenthesize in K&R style. [Bracketing]<br>
* 2 Separate your control keywords from the following opening<br>
bracket. [Keywords]<br>
* 3 Don't separate subroutine or variable names from the<br>
following opening bracket. [Subroutines and Variables]<br>
* 4 Don't use unnecessary parentheses for builtins and<br>
"honorary" builtins. [Builtins]<br>
* 5 Separate complex keys or indices from their surrounding<br>
brackets. [Keys and Indices]<br>
* 6 Use whitespace to help binary operators stand out from<br>
their operands. [Operators]<br>
* 7 Place a semicolon after every statement. [Semicolons]<br>
* 8 Place a comma after every value in a multiline list. [Commas]<br>
* 9 Use 78-column lines. [Line Lengths]<br>
* 10 Use four-column indentation levels. [Indentation]<br>
* 11 Indent with spaces, not tabs. [Tabs]<br>
* 12 Never place two statements on the same line. [Blocks]<br>
* 13 Code in paragraphs. [Chunking]<br>
* 14 Don't cuddle an else. [Elses]<br>
* 15 Align corresponding items vertically. [Vertical Alignment]<br>
* 16 Break long expressions before an operator. [Breaking Long Lines]<br>
* 17 Factor out long expressions in the middle of statements.<br>
[Non-Terminal Expressions]<br>
* 18 Always break a long expression at the operator of the<br>
lowest possible precedence. [Breaking by Precedence]<br>
* 19 Break long assignments before the assignment operator. [Assignments]<br>
* 20 Format cascaded ternary operators in columns. [Ternaries]<br>
* 21 Parenthesize long lists. [Lists]<br>
* 22 Enforce your chosen layout style mechanically. [Automated Layout]<br>
Chapter 3, [Naming Conventions]<br>
* 23 Use grammatical templates when forming identifiers. [Identifiers]<br>
* 24 Name booleans after their associated test. [Booleans]<br>
* 25 Mark variables that store references with a _ref suffix.<br>
[Reference Variables]<br>
* 26 Name arrays in the plural and hashes in the singular.<br>
[Arrays and Hashes]<br>
* 27 Use underscores to separate words in multiword identifiers.<br>
[Underscores]<br>
* 28 Distinguish different program components by case. [Capitalization]<br>
* 29 Abbr idents by prefx. [Abbreviations]<br>
* 30 Abbreviate only when the meaning remains unambiguous.<br>
[Ambiguous Abbreviations]<br>
* 31 Avoid using inherently ambiguous words in names. [Ambiguous Names]<br>
* 32 Prefix "for internal use only" subroutines with an<br>
underscore. [Utility Subroutines]<br>
Chapter 4, [Values and Expressions]<br>
* 33 Use interpolating string delimiters only for strings that<br>
actually interpolate. [String Delimiters]<br>
* 34 Don't use "" or '' for an empty string. [Empty Strings]<br>
* 35 Don't write one-character strings in visually ambiguous<br>
ways. [Single-Character Strings]<br>
* 36 Use named character escapes instead of numeric escapes.<br>
[Escaped Characters]<br>
* 37 Use named constants, but don't use constant. [Constants]<br>
* 38 Don't pad decimal numbers with leading zeros. [Leading Zeros]<br>
* 39 Use underscores to improve the readability of long numbers.<br>
[Long Numbers]<br>
* 40 Lay out multiline strings over multiple lines. [Multiline Strings]<br>
* 41 Use a heredoc when a multiline string exceeds two lines.<br>
[Here Documents]<br>
* 42 Use a "theredoc" when a heredoc would compromise your<br>
indentation. [Heredoc Indentation]<br>
* 43 Make every heredoc terminator a single uppercase identifier<br>
with a standard prefix. [Heredoc Terminators]<br>
* 44 When introducing a heredoc, quote the terminator. [Heredoc Quoters]<br>
* 45 Don't use barewords. [Barewords]<br>
* 46 Reserve => for pairs. [Fat Commas]<br>
* 47 Don't use commas to sequence statements. [Thin Commas]<br>
* 48 Don't mix high- and low-precedence booleans.<br>
[Low-Precedence Operators]<br>
* 49 Parenthesize every raw list. [Lists]<br>
* 50 Use table-lookup to test for membership in lists of<br>
strings; use any() for membership of lists of anything else. [List<br>
Membership]<br>
Chapter 5, [Variables]<br>
* 51 Avoid using non-lexical variables. [Lexical Variables]<br>
* 52 Don't use package variables in your own development.<br>
[Package Variables]<br>
* 53 If you're forced to modify a package variable, localize it.<br>
[Localization]<br>
* 54 Initialize any variable you localize. [Initialization]<br>
* 55 use English for the less familiar punctuation variables.<br>
[Punctuation Variables]<br>
* 56 If you're forced to modify a punctuation variable, localize<br>
it. [Localizing Punctuation Variables]<br>
* 57 Don't use the regex match variables. [Match Variables]<br>
* 58 Beware of any modification via $_. [Dollar-Underscore]<br>
* 59 Use negative indices when counting from the end of an<br>
array. [Array Indices]<br>
* 60 Take advantage of hash and array slicing. [Slicing]<br>
* 61 Use a tabular layout for slices. [Slice Layout]<br>
* 62 Factor large key or index lists out of their slices. [Slice<br>
Factoring]<br>
Chapter 6, [Control Structures]<br>
* 63 Use block if, not postfix if. [If Blocks]<br>
* 64 Reserve postfix if for flow-of-control statements. [Postfix<br>
Selectors]<br>
* 65 Don't use postfix unless, for, while, or until. [Other<br>
Postfix Modifiers]<br>
* 66 Don't use unless or until at all. [Negative Control Statements]<br>
* 67 Avoid C-style for statements. [C-Style Loops]<br>
* 68 Avoid subscripting arrays or hashes within loops.<br>
[Unnecessary Subscripting]<br>
* 69 Never subscript more than once in a loop. [Necessary Subscripting]<br>
* 70 Use named lexicals as explicit for loop iterators.<br>
[Iterator Variables]<br>
* 71 Always declare a for loop iterator variable with my.<br>
[Non-Lexical Loop Iterators]<br>
* 72 Use map instead of for when generating new lists from old.<br>
[List Generation]<br>
* 73 Use grep and first instead of for when searching for values<br>
in a list. [List Selections]<br>
* 74 Use for instead of map when transforming a list in place.<br>
[List Transformation]<br>
* 75 Use a subroutine call to factor out complex list<br>
transformations. [Complex Mappings]<br>
* 76 Never modify $_ in a list function. [List Processing Side Effects]<br>
* 77 Avoid cascading an if. [Multipart Selections]<br>
* 78 Use table look-up in preference to cascaded equality tests.<br>
[Value Switches]<br>
* 79 When producing a value, use tabular ternaries. [Tabular Ternaries]<br>
* 80 Don't use do...while loops. [do-while Loops]<br>
* 81 Reject as many iterations as possible, as early as<br>
possible. [Linear Coding]<br>
* 82 Don't contort loop structures just to consolidate control.<br>
[Distributed Control]<br>
* 83 Use for and redo instead of an irregularly counted while. [Redoing]<br>
* 84 Label every loop that is exited explicitly, and use the<br>
label with every next, last, or redo. [Loop Labels]<br>
Chapter 7, [Documentation]<br>
* 85 Distinguish user documentation from technical<br>
documentation. [Types of Documentation]<br>
* 86 Create standard POD templates for modules and applications.<br>
[Boilerplates]<br>
* 87 Extend and customize your standard POD templates. [Extended<br>
Boilerplates]<br>
* 88 Put user documentation in source files. [Location]<br>
* 89 Keep all user documentation in a single place within your<br>
source file. [Contiguity]<br>
* 90 Place POD as close as possible to the end of the file. [Position]<br>
* 91 Subdivide your technical documentation appropriately.<br>
[Technical Documentation]<br>
* 92 Use block templates for major comments. [Comments]<br>
* 93 Use full-line comments to explain the algorithm.<br>
[Algorithmic Documentation]<br>
* 94 Use end-of-line comments to point out subtleties and<br>
oddities. [Elucidating Documentation]<br>
* 95 Comment anything that has puzzled or tricked you.<br>
[Defensive Documentation]<br>
* 96 Consider whether it's better to rewrite than to comment.<br>
[Indicative Documentation]<br>
* 97 Use "invisible" POD sections for longer technical<br>
discussions. [Discursive Documentation]<br>
* 98 Check the spelling, syntax, and sanity of your<br>
documentation. [Proofreading]<br>
Chapter 8, [Built-in Functions]<br>
* 99 Don't recompute sort keys inside a sort. [Sorting]<br>
* 100 Use reverse to reverse a list. [Reversing Lists]<br>
* 101 Use scalar reverse to reverse a scalar. [Reversing Scalars]<br>
* 102 Use unpack to extract fixed-width fields. [Fixed-Width Data]<br>
* 103 Use split to extract simple variable-width fields. [Separated Data]<br>
* 104 Use Text::CSV_XS to extract complex variable-width fields.<br>
[Variable-Width Data]<br>
* 105 Avoid string eval. [String Evaluations]<br>
* 106 Consider building your sorting routines with Sort::Maker.<br>
[Automating Sorts]<br>
* 107 Use 4-arg substr instead of lvalue substr. [Substrings]<br>
* 108 Make appropriate use of lvalue values. [Hash Values]<br>
* 109 Use glob, not <...>. [Globbing]<br>
* 110 Avoid a raw select for non-integer sleeps. [Sleeping]<br>
* 111 Always use a block with a map and grep. [Mapping and Grepping]<br>
* 112 Use the "non-builtin builtins". [Utilities]<br>
Chapter 9, [Subroutines]<br>
* 113 Call subroutines with parentheses but without a leading &.<br>
[Call Syntax]<br>
* 114 Don't give subroutines the same names as built-in<br>
functions. [Homonyms]<br>
* 115 Always unpack @_ first. [Argument Lists]<br>
* 116 Use a hash of named arguments for any subroutine that has<br>
more than three parameters. [Named Arguments]<br>
* 117 Use definedness or existence to test for missing arguments.<br>
[Missing Arguments]<br>
* 118 Resolve any default argument values as soon as @_ is<br>
unpacked. [Default Argument Values]<br>
* 119 Always return scalar in scalar returns. [Scalar Return Values]<br>
* 120 Make list-returning subroutines return the "obvious" value<br>
in scalar context. [Contextual Return Values]<br>
* 121 When there is no "obvious" scalar context return value,<br>
consider Contextual::Return instead. [Multi-Contextual Return Values]<br>
* 122 Don't use subroutine prototypes. [Prototypes]<br>
* 123 Always return via an explicit return. [Implicit Returns]<br>
* 124 Use a bare return to return failure. [Returning Failure]<br>
Chapter 10, [I/O]<br>
* 125 Don't use bareword filehandles. [Filehandles]<br>
* 126 Use indirect filehandles. [Indirect Filehandles]<br>
* 127 If you have to use a package filehandle, localize it first.<br>
[Localizing Filehandles]<br>
* 128 Use either the IO::File module or the three-argument form<br>
of open. [Opening Cleanly]<br>
* 129 Never open, close, or print to a file without checking the<br>
outcome. [Error Checking]<br>
* 130 Close filehandles explicitly, and as soon as possible. [Cleanup]<br>
* 131 Use while (<>), not for (<>). [Input Loops]<br>
* 132 Prefer line-based I/O to slurping. [Line-Based Input]<br>
* 133 Slurp a filehandle with a do block for purity. [Simple Slurping]<br>
* 134 Slurp a stream with Perl6::Slurp for power and simplicity.<br>
[Power Slurping]<br>
* 135 Avoid using *STDIN, unless you really mean it. [Standard Input]<br>
* 136 Always put filehandles in braces within any print<br>
statement. [Printing to Filehandles]<br>
* 137 Always prompt for interactive input. [Simple Prompting]<br>
* 138 Don't reinvent the standard test for interactivity. [Interactivity]<br>
* 139 Use the IO::Prompt module for prompting. [Power Prompting]<br>
* 140 Always convey the progress of long non-interactive<br>
operations within interactive applications. [Progress Indicators]<br>
* 141 Consider using the Smart::Comments module to automate your<br>
progress indicators. [Automatic Progress Indicators]<br>
* 142 Avoid a raw select when setting autoflushes. [Autoflushing]<br>
Chapter 11, [References]<br>
* 143 Wherever possible, dereference with arrows. [Dereferencing]<br>
* 144 Where prefix dereferencing is unavoidable, put braces<br>
around the reference. [Braced References]<br>
* 145 Never use symbolic references. [Symbolic References]<br>
* 146 Use weaken to prevent circular data structures from leaking<br>
memory. [Cyclic References]<br>
Chapter 12, [Regular Expressions]<br>
* 147 Always use the /x flag. [Extended Formatting]<br>
* 148 Always use the /m flag. [Line Boundaries]<br>
* 149 Use \A and \z as string boundary anchors. [String Boundaries]<br>
* 150 Use \z, not \Z, to indicate "end of string". [End of String]<br>
* 151 Always use the /s flag. [Matching Anything]<br>
* 152 Consider mandating the Regexp::Autoflags module. [Lazy Flags]<br>
* 153 Use m{...} in preference to /.../ in multiline regexes.<br>
[Brace Delimiters]<br>
* 154 Don't use any delimiters other than /.../ or m{...}. [Other<br>
Delimiters]<br>
* 155 Prefer singular character classes to escaped<br>
metacharacters. [Metacharacters]<br>
* 156 Prefer named characters to escaped metacharacters. [Named Characters]<br>
* 157 Prefer properties to enumerated character classes. [Properties]<br>
* 158 Consider matching arbitrary whitespace, rather than<br>
specific whitespace characters. [Whitespace]<br>
* 159 Be specific when matching "as much as possible".<br>
[Unconstrained Repetitions]<br>
* 160 Use capturing parentheses only when you intend to capture.<br>
[Capturing Parentheses]<br>
* 161 Use the numeric capture variables only when you're sure<br>
that the preceding match succeeded. [Captured Values]<br>
* 162 Always give captured substrings proper names. [Capture Variables]<br>
* 163 Tokenize input using the /gc flag. [Piecewise Matching]<br>
* 164 Build regular expressions from tables. [Tabular Regexes]<br>
* 165 Build complex regular expressions from simpler pieces.<br>
[Constructing Regexes]<br>
* 166 Consider using Regexp::Common instead of writing your own<br>
regexes. [Canned Regexes]<br>
* 167 Always use character classes instead of single-character<br>
alternations. [Alternations]<br>
* 168 Factor out common affixes from alternations. [Factoring Alternations]<br>
* 169 Prevent useless backtracking. [Backtracking]<br>
* 170 Prefer fixed-string eq comparisons to fixed-pattern regex<br>
matches. [String Comparisons]<br>
Chapter 13, [Error Handling]<br>
* 171 Throw exceptions instead of returning special values or<br>
setting flags. [Exceptions]<br>
* 172 Make failed builtins throw exceptions too. [Builtin Failures]<br>
* 173 Make failures fatal in all contexts. [Contextual Failure]<br>
* 174 Be careful when testing for failure of the system builtin.<br>
[Systemic Failure]<br>
* 175 Throw exceptions on all failures, including recoverable<br>
ones. [Recoverable Failure]<br>
* 176 Have exceptions report from the caller's location, not from<br>
the place where they were thrown. [Reporting Failure]<br>
* 177 Compose error messages in the recipient's dialect. [Error Messages]<br>
* 178 Document every error message in the recipient's dialect.<br>
[Documenting Errors]<br>
* 179 Use exception objects whenever failure data needs to be<br>
conveyed to a handler. [OO Exceptions]<br>
* 180 Use exception objects when error messages may change.<br>
[Volatile Error Messages]<br>
* 181 Use exception objects when two or more exceptions are<br>
related. [Exception Hierarchies]<br>
* 182 Catch exception objects in most-derived-first order.<br>
[Processing Exceptions]<br>
* 183 Build exception classes automatically. [Exception Classes]<br>
* 184 Unpack the exception variable in extended exception<br>
handlers. [Unpacking Exceptions]<br>
Chapter 14, [Command-Line Processing]<br>
* 185 Enforce a single consistent command-line structure.<br>
[Command-Line Structure]<br>
* 186 Adhere to a standard set of conventions in your<br>
command-line syntax. [Command-Line Conventions]<br>
* 187 Standardize your meta-options. [Meta-options]<br>
* 188 Allow the same filename to be specified for both input and<br>
output. [In-situ Arguments]<br>
* 189 Standardize on a single approach to command-line<br>
processing. [Command-Line Processing]<br>
* 190 Ensure that your interface, run-time messages, and<br>
documentation remain consistent. [Interface Consistency]<br>
* 191 Factor out common command-line interface components into a<br>
shared module. [Interapplication Consistency]<br>
Chapter 15, [Objects]<br>
* 192 Make object orientation a choice, not a default. [Using OO]<br>
* 193 Choose object orientation using appropriate criteria. [Criteria]<br>
* 194 Don't use pseudohashes . [Pseudohashes]<br>
* 195 Don't use restricted hashes. [Restricted Hashes]<br>
* 196 Always use fully encapsulated objects. [Encapsulation]<br>
* 197 Give every constructor the same standard name. [Constructors]<br>
* 198 Don't let a constructor clone objects. [Cloning]<br>
* 199 Always provide a destructor for every inside-out class. [Destructors]<br>
* 200 When creating methods, follow the general guidelines for<br>
subroutines. [Methods]<br>
* 201 Provide separate read and write accessors. [Accessors]<br>
* 202 Don't use lvalue accessors. [Lvalue Accessors]<br>
* 203 Don't use the indirect object syntax. [Indirect Objects]<br>
* 204 Provide an optimal interface, rather than a minimal one.<br>
[Class Interfaces]<br>
* 205 Overload only the isomorphic operators of algebraic<br>
classes. [Operator Overloading]<br>
* 206 Always consider overloading the boolean, numeric, and<br>
string coercions of objects. [Coercions]<br>
Chapter 16, [Class Hierarchies]<br>
* 207 Don't manipulate the list of base classes directly. [Inheritance]<br>
* 208 Use distributed encapsulated objects. [Objects]<br>
* 209 Never use the one-argument form of bless. [Blessing Objects]<br>
* 210 Pass constructor arguments as labeled values, using a hash<br>
reference. [Constructor Arguments]<br>
* 211 Distinguish arguments for base classes by class name as<br>
well. [Base Class Initialization]<br>
* 212 Separate your construction, initialization, and destruction<br>
processes. [Construction and Destruction]<br>
* 213 Build the standard class infrastructure automatically.<br>
[Automating Class Hierarchies]<br>
* 214 Use Class::Std to automate the deallocation of attribute<br>
data. [Attribute Demolition]<br>
* 215 Have attributes initialized and verified automatically.<br>
[Attribute Building]<br>
* 216 Specify coercions as :STRINGIFY, :NUMERIFY, and :BOOLIFY<br>
methods. [Coercions]<br>
* 217 Use :CUMULATIVE methods instead of SUPER:: calls.<br>
[Cumulative Methods]<br>
* 218 Don't use AUTOLOAD(). [Autoloading]<br>
Chapter 17, [Modules]<br>
* 219 Design the module's interface first. [Interfaces]<br>
* 220 Place original code inline. Place duplicated code in a<br>
subroutine. Place duplicated subroutines in a module. [Refactoring]<br>
* 221 Use three-part version numbers. [Version Numbers]<br>
* 222 Enforce your version requirements programmatically.<br>
[Version Requirements]<br>
* 223 Export judiciously and, where possible, only by request. [Exporting]<br>
* 224 Consider exporting declaratively. [Declarative Exporting]<br>
* 225 Never make variables part of a module's interface.<br>
[Interface Variables]<br>
* 226 Build new module frameworks automatically. [Creating Modules]<br>
* 227 Use core modules wherever possible. [The Standard Library]<br>
* 228 Use CPAN modules where feasible. [CPAN]<br>
Chapter 18, [Testing and Debugging]<br>
* 229 Write the test cases first. [Test Cases]<br>
* 230 Standardize your tests with Test::Simple or Test::More.<br>
[Modular Testing]<br>
* 231 Standardize your test suites with Test::Harness. [Test Suites]<br>
* 232 Write test cases that fail. [Failure]<br>
* 233 Test both the likely and the unlikely. [What to Test]<br>
* 234 Add new test cases before you start debugging. [Debugging<br>
and Testing]<br>
* 235 Always use strict. [Strictures]<br>
* 236 Always turn on warnings explicitly. [Warnings]<br>
* 237 Never assume that a warning-free compilation implies<br>
correctness. [Correctness]<br>
* 238 Turn off strictures or warnings explicitly, selectively,<br>
and in the smallest possible scope. [Overriding Strictures]<br>
* 239 Learn at least a subset of the perl debugger. [The Debugger]<br>
* 240 Use serialized warnings when debugging "manually". [Manual Debugging]<br>
* 241 Consider using "smart comments" when debugging, rather than<br>
warn statements. [Semi-Automatic Debugging]<br>
Chapter 19, [Miscellanea]<br>
* 242 Use a revision control system. [Revision Control]<br>
* 243 Integrate non-Perl code into your applications via the<br>
Inline:: modules. [Other Languages]<br>
* 244 Keep your configuration language uncomplicated. [Configuration Files]<br>
* 245 Don't use formats. [Formats]<br>
* 246 Don't tie variables or filehandles. [Ties]<br>
* 247 Don't be clever. [Cleverness]<br>
* 248 If you must rely on cleverness, encapsulate it.<br>
[Encapsulated Cleverness]<br>
* 249 Don't optimize code—benchmark it. [Benchmarking]<br>
* 250 Don't optimize data structures—measure them. [Memory]<br>
* 251 Look for opportunities to use caches. [Caching]<br>
* 252 Automate your subroutine caching. [Memoization]<br>
* 253 Benchmark any caching strategy you use. [Caching for Optimization]<br>
* 254 Don't optimize applications—profile them. [Profiling]<br>
* 255 Be careful to preserve semantics when refactoring syntax. [Enbugging]<br>
<span class="HOEnZb"><font color="#888888">--<br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br>С уважением, Александр<br>Личный блог: <a href="http://eax.me/" target="_blank">http://eax.me/</a><br>Мой форум: <a href="http://it-talk.org/" target="_blank">http://it-talk.org/</a><br>
Мой Twitter: <a href="http://twitter.com/afiskon" target="_blank">http://twitter.com/afiskon</a><br><br>