[Moscow.pm] Так сколько же статей в Perl Best Practices?

[Alexandr Alexeev]

Очевидно, вы забыли посчитать нулевую статью из первой главы. Классическая
ошибка на +/- 1 :)

18 января 2012 г. 8:49 пользователь Иван Бессарабов <ivan на bessarabov.ru>написал:

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



-- 
С уважением, Александр
Личный блог: http://eax.me/
Мой форум: http://it-talk.org/
Мой Twitter: http://twitter.com/afiskon
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20120118/6048cff0/attachment-0001.html>