eeymoo/Clean-Code-zh
1
0
Fork 0
mirror of https://github.com/glen9527/Clean-Code-zh.git synced 2025-12-18 11:14:22 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

md 引入图片资源

Browse Source
This commit is contained in:
gdut-yy
2020-01-01 17:11:49 +08:00
parent 9085df5a8e
commit 7a4601dd50
19 changed files with 246 additions and 329 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/ch17.md
View File

@@ -1,9 +1,6 @@
# 第 17 章 Smells and Heuristics
Image
Image
Image
![](figures/ch17/17_1fig_martin.jpg)
In his wonderful book Refactoring,1 Martin Fowler identified many different “Code Smells.” The list that follows includes many of Martin’s smells and adds many more of my own. It also includes other pearls and heuristics that I use to practice my trade.
@@ -319,7 +316,7 @@ The simple use of explanatory variables makes it clear that the first matched gr
It is hard to overdo this. More explanatory variables are generally better than fewer. It is remarkable how an opaque module can suddenly become transparent simply by breaking the calculations up into well-named intermediate values.
G20: Function Names Should Say What They Do
Image
Look at this code:
```java
@@ -416,7 +413,7 @@ Everyone on the team should follow these conventions. This means that each team
If you would like to know what conventions I follow, you’ll see them in the refactored code in Listing B-7 on page 394, through Listing B-14.
G25: Replace Magic Numbers with Named Constants
Image
This is probably one of the oldest rules in software development. I remember reading it in the late sixties in introductory COBOL, FORTRAN, and PL/1 manuals. In general it is a bad idea to have raw numbers in your code. You should hide them behind well-named constants.
@@ -454,7 +451,7 @@ When you make a decision in your code, make sure you make it precisely. Know why
Ambiguities and imprecision in code are either a result of disagreements or laziness. In either case they should be eliminated.
G27: Structure over Convention
Image
Enforce design decisions with structure over convention. Naming conventions are good, but they are inferior to structures that force compliance. For example, switch/cases with nicely named enumerations are inferior to base classes with abstract methods. No one is forced to implement the switch/case statement the same way each time; but the base classes do enforce that concrete classes have all abstract methods implemented.