Очевидно, вы забыли посчитать нулевую статью из первой главы. Классическая ошибка на +/- 1 :)
18 января 2012 г. 8:49 пользователь Иван Бессарабов <[email protected]>написал: > На странице > 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 > [email protected] | http://moscow.pm.org > -- С уважением, Александр Личный блог: http://eax.me/ Мой форум: http://it-talk.org/ Мой Twitter: http://twitter.com/afiskon
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
