Chapter 1 Clean Code
There will be a code
bad code
The Price of Bad Code
__ Dream of a grand redesign
__ attitude
__ The primal challenge
__ The art of clean code?
__What is clean code?

Our thoughts
We are the authors
Boy Scout Rules
Prequels and Principles
conclusion
References

Chapter 2 Meaningful Names
As you go in
Make your intentions clear
Avoid misinformation
Distinguish meaningfully
Use a name that is easy to pronounce
Use a name that is easy to search for
Avoid encoding
__ Hungarian notation
__ member variable prefix
__ Interface class and implementation class

Don't brag about your memory.
Class name
Method name
Avoid quirky names
Use one word for one concept
Don't play with words
Use the name taken from the solution area.
Use names taken from the problem domain
Add meaningful context
Eliminate unnecessary context
In closing

Chapter 3 Functions
Make it small!
__ blocks and indentation

Just do one thing!
__ Section within the function

One level of abstraction per function!
__ Reading code from top to bottom: The rule of descent

Switch statement
Use descriptive names!
Function arguments
__ Commonly used unary format
__ flag argument
__ Binary function
__ ternary function
__ argument object
__ argument list
__ Verbs and Keywords

Don't cause side effects!
__ output arguments

Separate commands and queries!
Use exceptions rather than error codes!
__ Extracting Try/Catch blocks
__ Error handling is also a task.
__Error.java dependency magnet

Don't repeat yourself!
Structured Programming
How do you write a function?
conclusion
References

Chapter 4 Notes
Comments don't compensate for bad code.
Express your intentions with code!
Good comment
__ Legal Notes
__ Comments providing information
__ Comment explaining the intent
__ Annotations clarifying the meaning
__ Comment warning of results
__ TODO comment
__ Notes emphasizing the importance
__ Javadocs in the public API

bad comments
__ rambling comment
__ Comments that repeat the same story
__ Misleading comment
__ Mandatory comments
__ Comments recording history
__ There is a comment but it is not enough
__ scary noise
__ If it can be expressed as a function or variable, do not add a comment.
__ Comment indicating the location
__ Comments attached to closing parentheses
__ Annotations giving credit or attribution to the author
__ Commented code
__ HTML comments
__ Global Information
__ Too much information
__ Ambiguous relationship
__ function header
__ Javadocs in private code
__ Example

References

Chapter 5 Formatting
The purpose of formatting
Maintain appropriate line length
__ Write like a newspaper article
__ Separate concepts with blank lines
__ vertical density
__ vertical distance
__ vertical order

Fit horizontal format
__ Horizontal space and density
__ Horizontal alignment
__ indentation

fake range
Team Rules
Uncle Bob's Rules of Form

Chapter 6 Objects and Data Structures
Data abstraction
Data/object asymmetry
Demeter's Law
__ train crash
__ hybrid structure
__ Hide structure

Data transfer object
__Active Record

conclusion
References

Chapter 7 Error Handling
Use exceptions rather than error codes
Start with a Try-Catch-Finally statement.
Use unchecked exceptions
Give meaning to exceptions
Define exception classes considering the caller.
Define normal flow
Don't return null
Don't pass null
conclusion
References

Chapter 8 Boundaries
Using external code
Watch and learn the boundaries
Learning log4j
Learning tests are more than free
Using code that doesn't exist yet
clean borders
References

Chapter 9 Unit Testing
Three Rules of TDD
Maintain clean test code
__Tests provide flexibility, maintainability, and reusability.

Clean test code
__ Domain-specific testing language
__ double standards

One assert per test
__ One concept per test

FIRST
conclusion
References

Chapter 10 Class
class system
__ encapsulation

Classes should be small!
__ Single Responsibility Principle
__ Cohesion
__ Maintaining cohesion results in many small classes

Easy to change classes
__ Isolation from changes

References

Chapter 11 System
What if you build a city?
Separate system creation from system use.
__ Main separation
__ Factory
__ Dependency Injection

expansion
__ Cross-cutting interests

Java Proxy
Pure Java AOP framework
AspectJ perspective
Building a Test-Driven System Architecture
Optimize your decision-making
Use standards wisely when they have clear value.
The system requires a domain-specific language.
conclusion
References

Chapter 12: Creativity
Let's implement clean code with emergent design.
Simple Design Rule 1: Run Every Test
Simple Design Rules 2-4: Refactoring
Eliminate duplication
Express yourself
Minimize the number of classes and methods
conclusion
References

Chapter 13 Concurrency
Why is concurrency needed?
__ Superstitions and misunderstandings

Difficulty
Concurrency Defense Principle
__ Single Responsibility Principle (SRP)
__ Corollary: Limit the scope of the data
__ Follow-up: Use copies of data
__ Follow-up: Implement threads as independently as possible.

Understand the library
__ Thread-safe collection

Understand the execution model
__ Producer-Consumer
__Readers-Writers
__ Dining Philosophers

Understand the dependencies that exist between synchronized methods.
Make the syncing part small
Correct exit codes are difficult to implement
Testing threaded code
__ Treat nonsensical failures as temporary thread problems.
__ Let's make sequential code that doesn't consider multi-threading work properly.
__ Implement threaded code so that the multi-threaded code portion can be easily inserted into various environments.
__ Write code that uses multiple threads so that it can be adjusted to suit the situation.
__ Try to run more threads than the number of processors
__ Try running it on another platform
__ Insert auxiliary code instrument into the code and run it.
Try to force failure
__ Implement it yourself
__ Automation

conclusion
References

Chapter 14: Incremental Improvement
Args implementation
__ How did you make it?

Args: First draft
__ So it stopped
__ improve gradually

String argument
conclusion

Chapter 15: A Look Inside JUnit
JUnit framework
conclusion

Chapter 16: Refactoring SerialDate
First, let's turn it around
Second, let's fix it
conclusion
References

Chapter 17: Smells and Heuristics

annotation
__ C1: Inappropriate information
__ C2: Useless comments
__ C3: Duplicate comment
__ C4: Insincere comments
__ C5: Commented code

environment
__ E1: Need to build in multiple steps
__ E2: Testing should be done in multiple stages

function
__ F1: Too many arguments
__ F2: Output argument
__ F3: Flag argument
__ F4: Dead function

common
__ G1: Use multiple languages ​​in one source file
__ G2: Does not implement expected behavior
__ G3: Not handling boundaries correctly
__ G4: Ignoring safety procedures
__ G5: Duplicate
__ G6: Incorrect level of abstraction
__ G7: Base class depends on derived class
__ G8: Information overload
__ G9: Dead Code
__ G10: Vertical separation
__ G11: Lack of consistency
__ G12: Miscellaneous
__ G13: Artificial bonding
__ G14: Functional Greed
__ G15: Selector Arguments
__ G16: Ambiguous Intention
__ G17: Responsibility for wrongly erased
__ G18: Inappropriate static function
__ G19: Descriptive variables
__ G20: Functions with matching names and functions
__ G21: Understand the Algorithm
__ G22: Physically expose logical dependencies
__ G23: Use polymorphism over If/Else or Switch/Case statements.
__ G24: Follow standard notation
__ G25: Replace magic numbers with named constants
__ G26: Be precise
__ G27: Use structure over convention
__ G28: Encapsulate conditions
__ G29: Avoid negative conditions
__ G30: A function should do only one thing
__ G31: Hidden Temporal Combination
__ G32: Be consistent
__ G33: Encapsulate boundary conditions
__ G34: Functions should go down only one level of abstraction
__ G35: Put the settings information at the top level
__ G36: Avoid transitive search

Java
__ J1: Avoid long import lists and use wildcards
__ J2: Constants are not inherited
__ J3: Constants vs. Enums

name
__ N1: Use descriptive names
__ N2: Choose a name at the appropriate level of abstraction
__ N3: Use standard nomenclature if possible
__ N4: Clear name
__ N5: Use long names for long ranges
__ N6: Avoid encoding
__ N7: Describe the side effect by name.

test
__ T1: Insufficient testing
__ T2: Use coverage tools!
__ T3: Don't skip trivial tests
__ T4: Ignored tests mean ambiguity
__ T5: Test the boundary conditions
__ T6: Test thoroughly around bugs
__ T7: Look for failure patterns
__ T8: Examine the test coverage pattern
__ T9: Testing must be fast

conclusion
References

Appendix A Concurrency II

Client/Server Example
__ server
__ Add thread
__ Check out the server
__ conclusion

Possible execution paths
__ number of paths
__ Calculate the number of possible permutations
__ In-depth analysis
__ conclusion

Understand the library
__ Executor Framework
__ Non-blocking method that does not block the thread
__ Classes that are not safe in multi-threaded environments

Beware of dependencies between methods.
__ Tolerate failure
__ Client-based locking
__ Server-based locking

Increase throughput
__ Calculating throughput - single-threaded environment
__ Workload Calculation - Multi-threaded Environment

deadlock
__ Mutual Exclusion
__ Lock & Wait
__ No Preemption
__ Circular Wait
__ Breaking the mutual exclusion condition
__ Break lock & wait condition
__ Breaking the non-preemptive condition
__ Break circular wait condition
__ Testing multi-threaded code
__ Tools to help test threaded code

conclusion
Tutorial: Full Code Examples
__ Client/Server - Single-Threaded Version
__ Client/Server - Multi-threaded version

Appendix B org.jfree.date.SerialDate

Appendix C: Cross-Reference List of Heuristics

Epilogue
Glossary of terms
List of abbreviations
Search

Bad code still works.
But if the code isn't clean, the development organization will crawl.
Every year, countless hours and significant resources are wasted on messy code.
There is no reason to do that.

In this book, Robert Martin presents a revolutionary paradigm.
He and his colleagues at Object Mentor have distilled the best agile techniques for creating clean code "while developing" into a book that will instill the values ​​of software craftsmanship and elevate your programming skills.
If you just try.
What effort is required? You have to read the code.
A lot of code.
And as you read the code, you should also think about what is right and what is wrong with the code.
More importantly, it makes you reflect on your own values ​​as a professional and your dedication to your work as a craftsman.

This book is divided into three parts.
The first few chapters explain the principles, patterns, and practices of writing clean code.
The second part presents several case studies, which become increasingly complex.
Each case study is an exercise in cleaning up code—that is, replacing problematic code with more robust and efficient code.
The third part is the conclusion. The last chapter lists the heuristics and 'smells' collected while creating the case study.
As a result, we gain a knowledge base that describes how we think as we read, write, and organize code.


Readers of this book will learn:

* How to distinguish good code from bad code
* How to write good code and how to turn bad code into good code
* How to write good names, good functions, good objects, and good classes
* How to format your code for readability
* How to perfectly implement error handling without disrupting code logic.
* How to apply unit testing and test-driven development

This book is a must-read for programmers, software engineers, project managers, team leaders, and systems analysts who strive to create better code.