Pure code. Good programmer's guide - Robert C. Martin

Attention!

Book replaced by a new edition - check it out!

Table of contents

Foreword (13)

Introduction (19)

1. pure code (23)

• Let there be a code... (24)
• In search of the perfect code... (24)
• Total cost of clutter (25)
  
  • Commencement of a major design change (26)
  • Attitude (27)
  • The biggest puzzle (28)
  • The art of pure code? (28)
  • What's a pure code? (28)
• Schools of thought (34)
• We are the authors (35)
• Scouting principle (36)
• Predecessor and principles (36)
• Completion (36)
• Bibliography (37)

2 Significant names (39)

• Introduction (39)
• Use names that represent intentions (40)
• Avoiding disinformation (41)
• Creating clear differences (42)
• Creating names that can be pronounced (43)
• Use of easily searchable names (44)
• Avoiding coding (45)
  
  • Hungarian Notation (45)
  • Prefixes of ingredients (46)
  • Interfaces and implementations (46)
• Avoiding mental mapping (47)
• Class names (47)
• Names of methods (47)
• Don't be witty (48)
• Choose one word per concept (48)
• Don't make puns! (49)
• Use of solution domain names (49)
• Use of problem area names (49)
• Adding a meaningful context (50)
• Do not add an excessive context (51)
• Final word (52)

3. functions (53)

• Small features! (56)
  
  • Blocks and notches (57)
• Do one thing (57)
  
  • Sections within functions (58)
• One level of abstraction in function (58)
  
  • Reading the code from top to bottom - descending rule (58)
• Switch instructions (59)
• Use of descriptive names (61)
• Functional arguments (62)
  
  • Often used single-argument functions (62)
  • Marking arguments (63)
  • Two-argument functions (63)
  • Three-argument functions (64)
  • Object arguments (64)
  • List of arguments (65)
  • Verbs and keywords (65)
• Avoiding side effects (65)
  
  • Baseline arguments (66)
• Distribution of commands and queries (67)
• Using exceptions instead of returning error codes (67)
  
  • Separation of try-catch blocks (68)
  • Error handling is one operation (69)
  • Dependency attraction in Error.java (69)
• Do not repeat yourself (69)
• Structural programming (70)
• How to write such functions? (70)
• Termination (71)
• SetupTeardownIncluder (71)
• Bibliography (73)

4 Comments (75)

• Comments are not lipstick for the wrong code (77)
• Clear code requires no comments (77)
• Good comments (77)
  
  • Legal comments (77)
  • Information comments (78)
  • Explanation of intentions (78)
  • Explanation (79)
  • Consequence warnings (80)
  • TODO comments (80)
  • Reinforcement (81)
  • Javadoc comments in public API (81)
• Bad comments (81)
  
  • Gibberish (81)
  • Repeated comments (82)
  • Confusing comments (84)
  • Comments required (85)
  • Daily newspaper comments (85)
  • Comments introducing information noise (86)
  • Terrible noise (87)
  • Do not use comments if you can use a function or variable (88)
  • Item markers (88)
  • Comments in the closing buckles (88)
  • Attributes and notes (89)
  • Commented code (89)
  • HTML comments (90)
  • Non-local information (91)
  • Excessive information (91)
  • Unobvious calls (91)
  • Function headers (92)
  • Javadoc comments in non-public code (92)
  • Example (92)
• Bibliography (95)

5 Formatting (97)

• Formatting purpose (98)
• Vertical formatting (98)
  
  • Newspaper metaphor (99)
  • Vertical spacing between code segments (99)
  • Vertical density (101)
  • Vertical distance (101)
  • Vertical arrangement (105)
• Horizontal formatting (106)
  
  • Horizontal spacing and density (106)
  • Horizontal distribution (107)
  • Notches (109)
  • Empty ranges (110)
• Team rules (110)
• Uncle Bob's formatting rules (111)

6 Objects and data structures (113)

• Data extraction (113)
• Data and object antisymmetry (115)
• Demeter Law (117)
  
  • Train wrecks (118)
  • Hybrids (118)
  • Hiding the structure (119)
• Data transfer objects (119)
  
  • Active Record (120)
• Termination (121)
• Bibliography (121)

7 Error handling (123)

• Use of exceptions instead of return codes (124)
• Starting with writing the try-catch-finally instruction (125)
• Use of uncontrolled exceptions (126)
• Providing context through exceptions (127)
• Defining exception classes according to the needs of the originator (127)
• Definition of normal flow (129)
• We don't return null (130)
• We do not transfer null (131)
• Completion (132)
• Bibliography (132)

8 Borders (133)

• Use of third party code (134)
• Viewing and familiarising oneself with borders (136)
• Using log4j package (136)
• Advantages of the teacher tests (138)
• Use of a non-existent code (138)
• Pure boundaries (139)
• Bibliography (140)

9 Unit tests (141)

• Three TDD laws (142)
• Keeping tests clean (143)
  
  • Tests increase the possibilities (144)
• Clean tests (144)
  
  • Domain specific test languages (147)
  • Double standard (147)
• One assay per test (149)
  
  • One concept per test (150)
• F.I.R.S.T. (151)
• Completion (152)
• Bibliography (152)

10 Classes (153)

• Organisation of classes (153)
  
  • Hermetisation (154)
• The classes should be small! (154)
  
  • Principle of single liability (156)
  • Cohesion (158)
  • Maintaining consistency results in many small classes (158)
• Organisation of changes (164)
  
  • Isolating code modules before changes (166)
• Bibliography (167)

11 Systems (169)

• How would you build a city? (170)
• Separating system design from use (170)
  
  • Separation of main module (171)
  • Factories (172)
  • Dependency injection (172)
• Scaling up (173)
  
  • Separation (cutting) of problems (176)
• Java intermediaries (177)
• Clean Java AOP libraries (178)
• AspectJ (181)
• System architecture testing (182)
• Optimising decision making (183)
  
  • Use standards when they bring real value (183)
• Systems require domain-specific languages (184)
• Completion (184)
• Bibliography (185)

12 Project creation (187)

• Achieving project purity by developing it (187)
• Rule number 1 of simple design - the system passes all tests (188)
• Rules number 2 - 4 of simple design - reconstruction (188)
• No repetition (189)
• Code clarity (191)
• Minimum classes and methods (192)
• Completion (192)
• Bibliography (192)

13. concurrency (193)

• What is the purpose of concurrency? (194)
  
  • Myths and misunderstandings (195)
• Challenges (196)
• Rules for the defence of concurrency (196)
  
  • Principle of single liability (197)
  • Conclusion - reduction of data scope (197)
  • Request - use of copies of data (197)
  • Conclusion - the plots should be as independent as possible (198)
• Know the library in use (198)
  
  • Collections safe for threads (198)
• Explore the models (199)
  
  • Producer-consumer (199)
  • Reader-writer (200)
  • Feasting philosophers (200)
• Note the relationship between synchronised methods (201)
• Creating small synchronized sections (201)
• Writing the correct shutdown code is difficult (202)
• Thread code testing (202)
  
  • We treat accidental failures as potential multithreading problems (203)
  • At the beginning we run the code not using threads (203)
  • Our thread code should be able to be enabled (203)
  • Our thread code should be tunable (204)
  • We run more threads than we have processors (204)
  • We are launching tests on various platforms (204)
  • We're arming our code with elements trying to cause failures and forcing failures (205)
  • Manual instrumentation (205)
  • Automatic instrumentation (206)
• Completion (207)
• Bibliography (208)

14 Successful code cleansing (209)

• Implementation of Args class (210)
• Args - rough sketch (216)
• String arguments (228)
• Completion (261)

15. JUnit library structure (263)

• JUnit Library (264)
• Completion (276)

16 Reconstruction of the SerialDate class (277)

• We start with (278)
• Now we're improving (280)
• Completion (293)
• Bibliography (294)

17. odours of code and heuristics (295)

• Comments (296)
  
  • C1. Incorrect information (296)
  • C2. Outdated comments (296)
  • C3. Redundant comments (296)
  • C4. Wrongly written comments (297)
  • C5. Commented code (297)
• Environment (297)
  
  • E1. Building requires more than one step (297)
  • E2. Tests require more than one step (297)
• Functions (298)
  
  • F1. Excess arguments (298)
  • F2. Output arguments (298)
  • F3. Marker arguments (298)
  • F4. Still functions (298)
• General (298)
  
  • G1. Multiple languages in one source file (298)
  • G2. Obvious operation is not implemented (299)
  • G3. Improper operation under limit conditions (299)
  • G4. Security features removed (299)
  • G5. Repetitions (300)
  • G6. Code at an inappropriate abstraction level (300)
  • G7. Base classes depending on their derived classes (301)
  • G8. Too much information (302)
  • G9. Dead code (302)
  • G10. Vertical separation (303)
  • G11. Inconsistency (303)
  • G12. Dimming (303)
  • G13. Artificial couplings (303)
  • G14. Envy of function (304)
  • G15. Selective arguments (305)
  • G16. Dimming of intentions (305)
  • G17. Badly distributed responsibility (306)
  • G18. Inappropriate static methods (306)
  • G19. Use of descriptive variables (307)
  • G20. Names of functions should indicate what they do (307)
  • G21. Understand the algorithm (308)
  • G22. Conversion of logical to physical relationships (308)
  • G23. Use of polymorphism instead of if-else or switch-case instructions (309)
  • G24. Use of standard conventions (310)
  • G25. Replacement of magic numbers by fixed numbers (310)
  • G26. Precision (311)
  • G27. Pre-Convention structure (312)
  • G28. Hermetisation of conditions (312)
  • G29. Avoiding negative conditions (312)
  • G30. The functions should perform one operation (312)
  • G31. Hidden time feedback (313)
  • G32. Avoidance of any action (314)
  • G33. Boundary condition air-tightening (314)
  • G34. The functions should go into one level of abstraction (315)
  • G35. High level configurable data storage (316)
  • G36. Avoidance of passerby navigation (317)
• Java (317)
  
  • J1. Avoiding long import lists by using wildcards (317)
  • J2. We do not inherit constants (318)
  • J3. Fixed versus design types (319)
• Names (320)
  
  • N1. Selection of descriptive names (320)
  • N2. Selection of names at appropriate levels of abstraction (321)
  • N3. Use of standard nomenclature where possible (322)
  • N4. Unambiguous names (322)
  • N5. Use of long names for long ranges (323)
  • N6. Avoiding coding (323)
  • N7. Names should describe side effects (323)
• Tests (324)
  
  • T1. Insufficient tests (324)
  • T2. Use of coverage control tools (324)
  • T3. Do not skip simple tests (324)
  • T4. Ignored test is an indication of ambiguity (324)
  • T5. Limit conditions (324)
  • T6. Thorough testing of nearby errors (324)
  • T7. Error patterns reveal much (324)
  • T8. Test coverage patterns reveal much (325)
  • T9. Tests should be fast (325)
• Termination (325)
• Bibliography (325)

A: Concurrency II (327)

• Example customer-server (327)
  
  • Server (327)
  • Add threads (329)
  • Notes on the server (329)
  • Completion (331)
• Possible pathways (331)
  
  • Number of paths (332)
  • We're digging deeper (333)
  • Completion (336)
• Know the library you are using (336)
  
  • Executor Library (336)
  • Non-blocking solutions (337)
  • Secure Threadless Classes (338)
• Interdependencies between methods may damage the concurrent code (339)
  
  • Failure tolerance (340)
  • Locking at the customer (340)
  • Server lock (342)
• Increasing capacity (343)
  
  • Single-threaded capacity calculation (344)
  • Multi-threaded capacity calculation (344)
• Jamming (345)
  
  • Mutual exclusion (346)
  • Blocking and waiting (346)
  • No expropriation (346)
  • Cyclical expectation (346)
  • Prevention of mutual exclusion (347)
  • Prevention of blocking and waiting (347)
  • Enabling expropriation (348)
  • Prevention of cyclical expectation (348)
• Multi-threaded code testing (349)
• Tools to support thread-using code testing (351)
• Completion (352)
• Tutorial. Full example code (352)
  
  • Client-server without threads (352)
  • Client-server using threads (355)

B: org.jfree.date.SerialDate (357)

C: References to heurists (411)

Epilogue (413)