Code neat Way of reading notes

1th Chapter Neat Code
1.1 to have code
1.2 Bad Code
later equals never
1.3 The cost of confusion assumes that the upfront is not noticed. Late accession code, changes in efficiency are very low
1.3.1 Gorgeous new design
1.3.2 Attitude
1.3.3 Puzzle
The art of 1.3.4 Neat code
1.3.5 What is a neat code
1.4 Schools of thought 1.5 we are authors the time to read and write code may be 10:1. Ability to view your own writing records with the editor's playback 1.6 scout
1.7 Prequel and principles




The 2nd chapter meaningful naming
2.1 Introduction
2.2 Pairs in fact, the variable name is too arbitrary, haha, list1, OK these are meaningless 2.3 avoid misleading including list etc keyword, letter O and number 0, etc.
2.4 Make a meaningful distinction between the negative. Variable name: A1, A2, A3 avoid redundancy, do not appear variable, table fields to avoid table, string to avoid the occurrence of namestring-direct name is good 2.5 use the name of the read out of their own patchwork of words, so-called hump naming method, try to use The Complete Word
2.6 Use searchable names some constants, it is best not to use numbers directly, but to specify a variable name, the variable name can be easily searched for
2.7 Avoiding the use of coding
2.7.1 Hungarian notation Avoid using abbreviations like this
2.7.2 member prefixes avoid the use of prefixes, but a better one in android like to use M for private, etc., personal feeling better
2.7.3 interfaces and implementations the author does not like to start with the interface using I, and I want to just add the imp later
2.8 Avoid thinking map use only simple A, B, C and other abbreviations some words 2.9 class name
The class name and object name should be nounAnd noun phrases。 Can't make a verb. 2.10 Method Name Method name should be a verb or a verb phrase do not use the constructor, and use the corresponding public (the constructor is too often used, the name of these parameters is also more cost-minded, so this is not quite agreed) 2.11 Don't play cute variables called haha, banana
2.12 Each concept corresponding to a word in the project the control and manager appear at the same time, why not use one of them uniformly?
2.13 Do not use puns sometimes it may not be appropriate to add. Proportional Insert, apped. Add indicates the full meaning of the new addition.
2.14 Using the solution domain name to see the code is the program ape, so when the name of the time to consider more professional vocabulary.
2.15 Use of names originating from the problem areas involved
2.16 Adding a meaningful context can put related variables into a class, using this class to indicate context.
2.17 do not include the abbreviation for the item in the useless context name. It's totally unnecessary.
2.18 Last Words
The hardest part of taking a name is the need for good descriptive narrative skills and a common cultural background.


3rd Chapter function
3.1 Short do not write hundreds of lines of function
3.2 Just do one thing and try to make sure that every function only does a thing.
3.3 Each function an abstraction level reads code from top down: down rules
The 3.4 switch statement puts the switch into the factory, and there is no need to consider how it is implemented in detail.
3.5 Use descriptive descriptive name 3.6 The number of function parameters should be less than 3, the less the better3.6. General form of the 11-dollar function
3.6.2 Identification Parameters-Suppose you need to pass the method to true or false to indicate that the method must do two things
3.6.32-dollar function
3.6.43-dollar function
3.6.5-The parameter is assumed to be too large to encapsulate these parameters directly into an object
3.6.6 List-even if multiple parameters can be passed in. But more than 3 of them still have to be considered how to streamline
3.6.7 verb and keyword3.7 No side-effect method may require some kind of scene reduction with the ability to have the ideal result. For example, some can only be called at initialization time. The ability to output a parameter by naming checkpassowrdandinitializesession, the function's content is modified on the input parameters. This situation avoids or uses the name Appedfooter (StringBuffer report) as much as possible
3.8 delimited instruction and ask the hypothetical method to set the value of a variable, and there is a return value. Can be named setAndCheckIfExists3.9 use exception substitution return error code 3.9.1 extract the contents of the try block into a method by pulling out the Try/catch code block
3.9.2 error handling is just one thing.
3.9.3 Error.java Dependent Magnets
3.10 Do not repeatedly avoid the function of the project repeatedly code, but also remember to directly copy a function to a few places to use
3.11 Structured programming functions only short, occasionally return, break, continue statement no harm
3.12 How to write this function
3.13 Summary
3.14 Setupteardownincluder Program
3.15 references




4th Chapter Gaze
4.1 Gaze does not beautify bad code gaze aside from the lack of writing, it is possible to change the code and forget to change the corresponding gaze, causing the gaze above the code to actually not be the meaning of the following code.

4.2 Using code to illustrate
4.3 Good stare
4.3.1 Legal Information
4.3.2 provides information for the gaze-add a conforming sample to the regular form. The meaning of the return value is included in the function name.

4.3.3 's interpretation of intentions-code written in some places may not conform to common sense, but it is due to certain circumstances that must be written in such a way that it can be interpreted with gaze.
4.3.4 Interpretation
4.3.5 Alert-Considerations for code changes, etc.
4.3.6 Todo Gaze
4.3.7 magnification
4.3.8 Public API Javadoc-able to learn the next Javadoc
4.4 Bad Stare
4.4.1 muttered--some gaze did not explain things clearly, as the author wrote to himself charades 4.4.2 Extra gaze-function code is very easy to understand. But the gaze was very long written.
4.4.3 misleading gaze-a particular situation in which the gaze does not depict the narrative, but the use of the function is not the same as the gaze effect.

4.4.4-rule gaze-every variable name, every function has a gaze that is foolish and ridiculous.

4.4.5 Log Gaze-added who changed it. But now SVN and other code management tools can see the
4.4.6 Nonsense Stare
4.4.7 horrible crap.
4.4.8 When you can use a function or variable, don't stare.
4.4.9 location Tag-use////to separate some functions, not recommended in the book. But I personally feel that this will make the code clearer.
4.4.10 the gaze behind the brackets-multi-layered nesting. At the end of the parenthesis, add the end brackets that belong to which control keyword. Such a situation can be extracted into multiple methods
4.4.11 attribution and Attribution-no need, due to the source control system
4.4.12 stare out of the code-temporary unnecessary code can be deleted directly, not necessary to stare out. Ability to use source control system to find previous version number
4.4.13 HTML Gaze
4.4.14 Non-local information
4.4.15 too much information-the main need for the core information, not necessarily a large description of the narrative
4.4.16 not a clear link
4.4.17 function Header
4.4.18 in non-public code javadoc-public need to add Javadoc to tell the user some information, but the private method is very many times do not need
4.4.19 Example





5th Chapter Format
5.1 Purpose of the format
5.2 Vertical Format
5.2.1 to the newspaper can read from top to bottom, the top is more important.
The area code in the vertical direction between the 5.2.2 concepts is usually read from top to bottom, left to right.

Be sure to leave a blank space between functions. This makes it easier to read 5.2.3 in the vertical direction near the 5.2.4 vertical distance function variable declaration-near the use of the global variable-at the top of the class-related function-the function called by the current function should be placed vertically To a related concept-such as a function name prefix, or overloaded functions are put together
5.2.5 Vertical Order
5.3 Horizontal Format How many characters are placed in each line of code, it is not acceptable to have a horizontal scroll, so it is recommended to hold about 120 characters per line. Of course, the shorter the better.
5.3.1 in horizontal direction with a space near the equal sign (=), and the calculation symbol (*/) adds space around
5.3.2 Horizontal alignment Very many variables are variable name left side aligned. This is very nice, but it takes time to deal with a uniform format. And it's not much use except for beauty.
5.3.3 Indent 5.3.4 Empty range if the contents of the IF function have only one row without parentheses, so easy causes errors on misreading and modification. 5.4 Team Rules
5.5 Uncle Bob's formatting rules




6th chapter objects and data structures
6.1 Data Abstraction Setter/getter The thinking of adding these methods
6.2 Inverse symmetry of data and objects
6.3 Artemis
6.3.1 Train wreck
6.3.2 Mixed
6.3.3 Hidden structure
6.4 Data Transfer Objects
6.5 Summary
Object exposure behavior. Hides the data.



7th Chapter Error Handling
7.1 Using exceptions instead of return codes does not use returns in the method. Instead, use the exception mechanism provided by the programming language to intercept
7.2 Write try-catch-finally Statement 7.3 Use an uncontrolled exception 7.4 to give an environmental description of the occurrence of an exception
7.5 Define the exception class as required by the caller
7.6 Defining the general process 7.7 do not return a null value returns an empty string or an empty list (Collections.emptylist ())
7.8 do not pass a null value to avoid passing in a null value instead of inferring within a function (or null inference within a function, after all, write the code together.) Inevitably others will pass in)
7.9 Summary
7.10 References




8th Chapter Boundary
8.1 Using third-party code
8.2 Browsing and learning boundaries 8.3 learning log4j
8.4 The advantages of the learning test are not only free in the case of an API that does not fully understand the function, write a demo test whether it is self-understanding, it is cost-saving and accurate.
8.5 The interface is already defined using code that does not yet exist. Similar to writing test data.

8.6 Tidy borders
8.7 References




9th Unit Test
9.1 TDD Three Laws 1. Before writing a failed unit test. Not be able to write production code;
2. Just write a unit test that just can't be passed, not compile or pass.
3. You can only write production code that is just enough to pass the current failure test.

9.2 It is just as important to keep the test clean and test code as the production code. It needs to be thought, designed and cared for.
9.3 Neat test each test is presented in a construction-operation-Check (build-operate-check) mode.
9.3.1 test language for specific areas
9.3.2 double standard
9.4 Each test an assertion
9.5 f.i.r.s.t. High speed (FAST): Test execution should be fast enough.
Independent (independent): test should be independent of each other.
Repeatable (REPEATABLE): test should be repeated in any environment.

Self-sufficiency Verification (self-validating): The test should have a Boolean output.

      timely (timely) test should be prepared in time.
9.6 Summary





10th Class
10.1 class organization
10.2 class should be short
     10.2.1 single responsibility     & nbsp     suggests that the system should consist of very many short classes rather than a handful of huge classes. Each small class encapsulates a responsibility, and there is only one reason for the change, rather than the systematic behavior of achieving expectations with a few others.      10.2.2
     10.2.3 maintain cohesion and get a lot of short classes
10.3 organize for changes




11th Chapter System
11.1 How to build a city       discuss how to keep it neat at a higher level of abstraction-at the system level.

11.2 Separate the construction and use of the system
     11.2.1 decomposition main          constructors into main in the portal?
     11.2.2 factory           applications need to determine when an object is created to be able to use the factory.
     11.2.3 Dependency Injection           can analyze construction and use.
11.3 Expansion 11.4 java proxy
11.5 Pure Java AOP Framework
11.6 ASPECTJ aspects
11.7 Test Drive system Architecture
11.8 Optimization decision
11.9 Smart use added to the standard of demonstrable value
11.10 system requires domain-specific language
11.11 summary



12th Iteration
12.1 through iterative design to achieve neat purpose      kent Beck about "Simple Design" The four rules:     1. Perform all tests      2. Do not repeat      3. Expression of the program Ape's forehead intention      4. Reduce the number of classes and methods as much as possible 12.2 simple design Rule 1: Perform all tests
12.3 Simple design Rules: Refactoring
12.4 cannot repeat
12.5 expression Force
12.6 as few classes and methods as possible
12.7 summary


13th concurrent Programming
13.1 Why concurrent
13.2 challenges       Concurrent runs are unordered and require thread safety.

13.3 Concurrent Defense Principle 13.3.1 Single Responsibility principle method/class/component There should be only one reason for the change.     Recommendation: Split the concurrency and non-concurrent code away. 13.3.2 inference: Limit the data scope synchronized, keep in mind the data encapsulation. Access to data that may be shared is strictly restricted.
13.3.3 inference: Use data replicas to avoid data sharing. The data returned by multithreading is separate and is merged into the main thread after running.

13.3.4 Inference: Threads should be as independent as possible
13.4 Understanding Java Library Qualified resources-a fixed size or number of resources in a concurrency environment.

such as database connection box fixed-size read/write cache. Mutual exclusion-only one thread at a time can access shared data or shared resource threads hungry-a thread or a group of threads is banned for a very long time or permanently. For example: Always let the running fast thread run first. For example, a thread that runs fast is endless. A long-running thread will "starve" to deadlock-two or more threads waiting for each other to end up running.

Each thread has resources that are required by other threads and cannot get resources owned by other threads.     cannot be terminated. Live lock-a thread that runs in a consistent sequence, each of which wants to start, but finds that other threads are already "on the road".

For reasons of competition. Threads will continue to try to get started, but they won't be able to do so for a very long time, even if they never start.

13.5 Understanding the Run model
     *** 13.5.1 producer-consumer model           One or more productions threads create some work, and placed in the cache or queue. One or more consumer threads obtain and complete these jobs from the queue. The queue between producer consumers is a qualified resource.

13.5.2 Reader-Author model
13.5.3 Banquet philosopher
13.6 Beware of dependencies between synchronization methods avoid using multiple methods of a shared object.
13.7 Keep the sync area tiny
13.8 very difficult to write the correct shutdown code
13.9 Test Thread Code
13.9.1 pseudo-Failure as a possible threading problem
13.9.2 Enable non-threading code to work first
13.9.3 Writing pluggable Thread code
13.9.4 writing an adjustable thread code
13.9.5 execute more threads than the number of processors
13.9.6 execution on different platforms
13.9.7 device trial and error code
13.9.8 Hard-coded
13.9.9 Self-initiated
13.10 Summary
13.11 References


The 14th chapter gradually improves
14.1 The implementation of args how do I do that? To write neat code, you must first write dirty code. And then tidy it up. For example, write a composition, write a draft first. Write compositions and so on.
14.2 Args: Drafts
14.2.1 so I paused. After adding additional column requirements to modify the code, the ability to find out what code needs to be modified. The way to improve is to find out where these changes are: 1. Each parameter type must have a parser paradigm element to select the HashMap method for that type.

2. Each type needs to be parsed in the command line string and then converted to true type.

3. A getxxx method is required for each type of parameter. Returns the participant value to the caller according to its true type.

14.2.2 Progressive
14.3 string number of references
14.4 Summary The JUnit test has been written before the change, which guarantees that the system function will not be affected by each change.

Find out where the explosion will grow later. Add a variable, such as a small range of steps, each change will need to pass the JUnit test.



Chapter 15th JUnit Insider
15.1 JUnit Framework
15.2 Summary



16th Chapter Reconstruction Serialdate
16.1 First, let it work
16.2 Let it do the right
16.3 Summary
16.4 References


17th Chapter taste and Revelation Gaze
C1. Inappropriate gaze
Allow inappropriate gaze to be saved to the source control system.
C2. Abandoned gaze
An outdated, unrelated, or incorrect gaze is an abandoned gaze that should not be retained must be deleted immediately.
C3. Redundancy of gaze
Gaze should talk about something that the code does not mention. Otherwise, it is redundant.
C4. A bad stare
The gaze that is worth writing must write the best gaze correctly, assuming that it is not written.

C5. Staring out the code
The Stare code must be deleted.
Environment
E1. Building that requires multi-step talent implementation
The build system should be a single step operation.
E2. Tests that require a multi-step ability to achieve
Only a single instruction is required to perform all unit tests.
Function
F1. Excessive number of references
The less the function should be, the better, resolutely avoid the function with 3 parameters.
F2. Output parameters
Output parameters are violated directly, and the output parameters are resisted.
F3. Identification of references
Boolean parameters are confusing and should be wiped out.
F4. Dead function






The function that is never called should be removed.

General issues
G1. A single source file exists in multiple languages
Minimize the number and range of source file languages.
G2. Apparent behavior not being fulfilled
Following the "least surprising principle", a function or class should implement the behavior that other programs apes have reason to expect, and don't let other program apes see the code to understand the function.
G3. The wrong boundary behavior
The code should have the correct behavior, recourse to each boundary condition and conduct a full test.

G4. Neglect of security
Focus on the code that may be causing the problem, focusing on security and stability.

G5. Repeated
Eliminate repetitive code and use design patterns.
G6. Code at the wrong level of abstraction
Abstract and derived class conceptual models must be completely detached, such as: code that is related to implementation details should not appear in the base class.
G7. Base classes are dependent on derived classes
The base class should be ignorant of derived classes.
G8. Too much information
Class, the fewer variables the better, the hidden implementation. The fewer public interfaces the better.
G9. Dead Code
Find and delete all code that is not called.
G10. Vertical separation
Variables and functions should be defined close to the called Code.
G11. Inconsistencies
Function variables should be mindedness, consistent, and make the code easy to read and change.
G12. Confusing
A useless variable. Functions that are not called, the gaze without the amount of information should be cleaned out.
G13. Artificial coupling
Things that do not depend on each other should not be coupled.

G14. Feature Attachment






The methods of the class should be interested only in their own methods and variables, and should not be favored by other classes of methods and variables.

G15. Selection of operator parameters
Avoid Boolean type parameters. Use polymorphic substitution.
G16. Obscure intentions
The code has to be as expressive as possible, and the explicit intent is more important than efficiency and performance.

G17. Responsibility for positional errors
"Least surprising principle", put the code in the reader's mind, rather than the place of convenience.
G18. Inappropriate static methods
Assuming that you want to use a static method, you must ensure that you do not have the opportunity to make it polymorphic.

G19. Use of explanatory variables
Breaking the computational process into a series of well-named intermediate values makes the program more readable.
G20. Function names should express their behavior G21. Understanding Algorithms
G22. Change logical dependencies to physical dependencies
Reliance should be obvious and should not be relied upon.
G23. Replace If/else or Switch/case G24 with polymorphism. Follow the standard conventions G25. Replace magic numbers with named constants G26. Accurate
Ambiguity and inaccuracy in the code are either the result of a different opinion, or it is due to laziness, which must be eliminated.
G27. Structure over contract G28. Package conditions
Encapsulate the condition into a method.
G29. Avoidance of negative conditions
Use positive conditions.

G30. The function should do only one thing G31. Masking timing Coupling
Creating sequential queues exposes sequential coupling, and each function generates a function that requires the number of parameters to guarantee the correct timing.

G32. Don't be arbitrary.






The code cannot be arbitrary. Need to be considered carefully.
G33. Encapsulating boundary conditions
For example: +1 or-1 operations must be encapsulated.

G34. Functions should only be at an abstract level
Encapsulates code that is not at an abstraction level, keeping each function at an abstraction level only.

G35. Placing configurable data at a higher level
Put configuration data and constants in the base class.
G36. Avoiding pass-through browsing
"Get the Artemis", write a shy code. Let the direct collaborators provide the services they need. Instead of browsing through the system.
Java
J1. Avoid too long import manifest J2 by using wildcards. Do not inherit constant J3. Constant vs. Enumeration
Use enum Enum instead of constant.

Name
N1. Descriptive descriptive name
The corresponding readability of the name has a 90% effect and must be carefully named.
N2. The name should match the level of abstraction
Do not take the name of the communication implementation: Take the name that reflects the class or function abstraction level.

N3. Use the standard nomenclature N4 whenever possible. Unambiguous name
N5. Choose a longer name for a larger scope N6. Avoid coding
You should not include a type or range of information in the name, such as a prefix such as m_,f.
N7. Name should indicate side effects
The name should describe all the information for a class, variable, or function and should not hide the side effects.






Test T1. Insufficient test
Make sure you have enough tests.
T2. Using Coverage Tools
Coverage tools are better able to find the modules, classes, and functions that are under test.
T3. Don't skip the small test.
T4. A neglected test is a question of uncertain things.
Use @ignore to express our doubts about the need.
T5. Test boundary conditions
Boundary interpretation errors are not uncommon. Boundary conditions must be tested.
T6. Comprehensive testing of similar defects
Defects tend to converge, assuming a flaw is found in the function. So it's a full test of this function.
T7. The model of test failure is instructive
You can find the problem by testing failure.
T8. Model of test coverage is instructive
By testing coverage, it is often possible to find clues to the test failure.
T9. Test should be high speed
A slow test causes the time to be skipped, causing a possible failure.

Code neat Way of reading notes