CONTENIDO:CLEAN CODE
There Will Be Code
Bad Code
The Total Cost of Owning a Mess
Schools of Thought
We Are Authors
The Boy Scout Rule
Prequel and Principles
MEANINGFUL NAMES
Introduction
Use Intention-Revealing Names
Avoid Disinformation
Make Meaningful Distinctions
Use Pronounceable Names
Use Searchable Names
Avoid Encodings
Avoid Mental Mapping
Class Names
Method Names
Don't Be Cute
Pick One Word per Concept
Don't Pun
Use Solution Domain Names
Use Problem Domain Names
Add Meaningful Context
Don't Add Gratuitous Context
Final Words
FUNCTIONS
Small!
Do One Thing
One Level of Abstraction per Function
Switch Statements
Use Descriptive Names
Function Arguments
Have No Side Effects
Command Query Separation
Prefer Exceptions to Returning Error Codes
Don't Repeat Yourself
Structured Programming
How Do You Write Functions Like This?
SetupTeardownIncluder
COMMENTS
Comments Do Not Make Up for Bad Code
Explain Yourself in Code
Good Comments
Bad Comments
FORMATTING
The Purpose of Formatting
Vertical Formatting
Horizontal Formatting
Team Rules
Uncle Bob's Formatting Rules
Objects and Data Structures
Data Abstraction
Data/Object Anti-Symmetry
The Law of Demeter
Data Transfer Objects
Conclusion
ERROR HANDLING
Use Exceptions Rather Than Return Codes
Write Your Try-Catch-Finally Statement First
Use Unchecked Exceptions
Provide Context with Exceptions
Define Exception Classes in Terms of a Caller's Needs
Define the Normal Flow
Don't Return Null
Don't Pass Null
Conclusion
BOUNDARIES
Using Third-Party Code
Exploring and Learning Boundaries
Learning logj
Learning Tests Are Better Than Free
Using Code That Does Not Yet Exist
Clean Boundaries
UNIT TESTS
The Three Laws of TDD
Keeping Tests Clean
Clean Tests
One Assert per Test
F.I.R.S.T.
Conclusion
CLASSES
Class Organization
Classes Should Be Small!
Organizing for Change SYSTEMS
How Would You Build a City?
Separate Constructing a System from Using It
Scaling Up
Java Proxies
Pure Java AOP Frameworks
AspectJ Aspects
Test Drive the System Architecture
Optimize Decision Making
Use Standards Wisely, When They Add Demonstrable Value
Systems Need Domain-Specific Languages
EMERGENCE
Getting Clean via Emergent Design
Simple Design Rule : Runs All the Tests
Simple Design Rules -: Refactoring
No Duplication
Expressive
Minimal Classes and Methods
Conclusion
CONCURRENCY
Why Concurrency?
Challenges
Concurrency Defense Principles
Know Your Library
Know Your Execution Models
Beware Dependencies Between Synchronized Methods
Keep Synchronized Sections Small
Writing Correct Shut-Down Code Is Hard
Testing Threaded Code
UCCESSIVE REFINEMENT
Args Implementation
Args: The Rough Draft
String Arguments
Conclusion
JUNIT INTERNALS
The JUnit Framework
REFACTORING SERIALDATE
First, Make It Work
Then Make It Right
SMELLS AND HEURISTICS
Comments
Environment
Functions
General
Java
Names
Tests
Conclusion
APPENDIX
A: CONCURRENCY II
Client/Server Example
Possible Paths of Execution
Knowing Your Library
Dependencies Between Methods Can Break Concurrent Code
Increasing Throughput
Deadlock
Testing Multithreaded Code
Tool Support for Testing Thread-Based Code
Tutorial: Full Code Examples
B: org.jfree.date.SerialDate
C: Cross References of Heuristics
Epilogue
Index
