Code neat Way of reading notes

Code neat way   Preface how to work   read a lot of code   find the pros and cons the first chapter neat code do not stay later, equal to never rotten code affects productivity code cleanliness not only about efficiency, but also about survival good code   C + + parent &nbsp ;  minimizes dependencies, facilitates maintenance    performance tuning, prevents changes that lead to confusion    layered strategy Perfect error handling code    code logic straightforward when called defect hard to hide   broken window theory &N bsp;  broken windows open up the building to decadent road   only contain the necessary things, decisive refusal   TDD has unit test, acceptance testing, less dependency, less API   smaller the better   less code repetition Scout Army   Make the camp cleaner than when you come. Chapter II meaningful naming veritable   do not have magic number to avoid misleading   best not to use list container names such as accountlist   avoid using different smaller names   avoid using o O 0 L 1 This word makes a meaningful distinction using a readable name using a searchable name to avoid encoding   do not use ishapefactory to encode   to implement encoding such as Shapefactoryimpl avoid thinking map   should not let the reader Translate your name into their well-known names in the brain   clear is the King class name   is a noun or noun phrase   Avoid using the manager Processor data Info class name   overloading the constructor with a static factory method name that describes the parameters Each concept a word get fetch avoids puns the word polysemy third chapter function short   function should not be longer than one screen   20 row cap best   If Elese while statement code block should only one line do one thing   judge Whether to do one thing, see if you can break out a function, the function is not only a simple reinterpretation of its implementation   if a function just does the same level of abstraction in the function name, then it rents one thing. Each function is an abstract hierarchy that uses descriptive text   naming methods to remain consistent    tell a story abstract factory instead of switchStatement function parameters   Ideally 0 parameters   try to avoid three parameters, enough reason to exceed three   try to use return values instead of output parameters such as void Transstringbuffer out) and StringBuffer trans ( StringBuffer in) The latter good   should not be used to represent parameters, such as render (true) should use two independent functions to replace the   two function to pay the price, you can through the member variables, abstract new classes to avoid   multiple parameters, Parameter objects should be considered   cannot have side effects    cannot produce other potential actions   delimited directives and queries    either do something or answer something, and you can't use exception substitution to return an error code   error handling code from Detach the main code path and don't repeat yourself how to write functions   write, Polish, decompose, modify name, eliminate repetition fourth comment comments The proper usage is to compensate for the failure of the code to express the intention to spend time cleaning code, much better than writing comments, simple to order created in the annotation description consistent function Good notes   Legal information   comment on information   interpretation of intent   alerts    Large operations    general use @Ignore Close test cases bad comments   mumbling   Extra comments   Misleading comments   rules-based comments   journaled comments   Nonsense comments   can use a function live variable don't use comments   parentheses after comments    like}//TR Y    should shorten functions, refactor code   attribution and attribution    should rely on source control system   commented out code The purpose of the fifth Chapter format format   code readability affects maintainability and extensibility of vertical lattice   Short files are easier to understand than long files   to learn from newspapers there is an outline of a single space in each group of code, the hierarchy   the role of the vertical compartment in the vertical direction   close to the    tightly related code to Close, and cannot be separated by annotations   vertical distance    Local variables should be close to where they are used, at the top of the function    entity variables should be declared at the top of the class    related functions     a function calls another function, should be put together      Callers above the callee    concept functions should be put together, such as overloaded functions    vertical order     top-down display function call dependent sequential landscape format   The upper line of code should be 120 characters   try not to drag the scrollbar   horizontal spacer with a space character around the    assignment operator to emphasize the purpose    function names and opening parentheses without spaces, closely related    parameter one by one in parentheses separated, emphasizing comma   horizontal to its    modifier, parameter type, parameter name start on the same vertical team planning   formatting rules team decision   Same rule, with IDE best code format   member variable declaration should be close to   with the constructor should have a certain interval   method calls up and down   structure compact   method There is a gap between   while for if only one sentence, do not use {} The sixth chapter Abstract objects and data structures   using interfaces, without exposing details, even the Get set method may expose the interface   to render an object containing data data objects in the best way an object's anti-type   objects hide the data in the abstract   data structure exposes its   Process code and object-oriented code    procedural code It is difficult to add new data structures, because all functions must be modified    object-oriented code is difficult to add new functions, because all classes of the de-Boltzmann law must be modified   The module should not be aware of the internal wake   hide internal structure of the object it is manipulating   class C method F should only invoke object methods    C    F created Objects    objects passed as parameters to F &nbsp ;  C's Entity variables hold objects   hidden structures know as little as possible data transfer objects DTO data transfer Objects &NBsp Only public variables, no function seventh error handling error handling can not mess up the logic code encountered an error, it is best to throw an exception try-catch-finally   defines a range   Try part can be canceled at any time, in the Catch statement continuation Controllable exception violation Open/Closed principle   The caller's method signature must be modified after the exception is thrown the life exception   destroy encapsulation gives the environment description of the exception to occur   failed action   failure type packaging third-party API   reduce reliance on him   NO Very painful. Code base   Easy mock and simulation   try to encapsulate your own exceptions do not return a null value   return a special object   you can return an empty list collections.emptylist () do not pass null values   Unless the API requires that the null value is not passed as far as possible eighth chapter boundary clean boundary   Boundary code need to clean segmentation and define desired test   Avoid too much knowledge of third-party specific information chapter Nineth Unit Test writing tests to ensure that every nook and cranny in the code is as I wish. Isolate and Forge The three laws of TDD   write code after testing   1. Production Code   2 is not writable until you write a unit test that cannot be passed. You can only write unit tests that just can't pass, not compile or pass   You can only write a production code that is just enough to pass the current failure test to test code and Production code as important as it is to keep the test clean, no unit tests, no expansion of production code, no changes to neat tests   neat tests three elements    readability    readability and nbsp;  readable   Clear, concise, enough expression   test three links    construct test data    operation test data    Verify that the operation has the desired result &N Bsp Number of assertions minimized    try one for one assertion   five rules for each test one concept neat test f.i.r.s.t   Fast Fast    fast running   standalone Independent   REPEATABLE repeatable    can be repeated in any environment  Self-sufficiency verification self-validating    should have Boolean output   timely timely    should be written in time

Code Neat Way of reading notes