作者:
Dustin Boswell
/
Trevor Foucher
出版社: 东南大学出版社
原作名: The Art of Readable Code: Simple and Practical Techniques for Writing Better Code
出版年: 2012-6
页数: 190
定价: 39.00元
ISBN: 9787564134471
出版社: 东南大学出版社
原作名: The Art of Readable Code: Simple and Practical Techniques for Writing Better Code
出版年: 2012-6
页数: 190
定价: 39.00元
ISBN: 9787564134471
内容简介 · · · · · ·
本书分析了许多的“糟糕代码”(这些代码有很多是出自于他们自己之手),他们试图厘清为什么这些代码如此糟糕以及如何改进这些代码。他们得出的结论是:你必须写出让他人(这里也包括你自己)花费最少时间能够理解的代码。
作者简介 · · · · · ·
博斯韦尔(Dustin Boswell),毕业于加州理工学院,在谷歌公司从事过五年的Web信息采集基础设施和广告营销计划的研究工作。他先后构建过多个Web站点,目前的主要研究兴趣在于大数据的处理和机器学习领域的相关技术。
富彻(Trevor Foucher),过去十年中先后在微软公司担任Windows及安全相关产品的工程师、经理和技术领导者的职务,现任职于谷歌公司,主要从事谷歌广告营销计划和搜索基础设施的研究工作。
目录 · · · · · ·
PREFACE
1 CODE SHOULD BE EASY TO UNDERSTAND
What Makes Code "Better"?
The Fundamental Theorem of Readability
Is Smaller Always Better?
Does Time—Till—Understanding Conflict with Other Goals?
· · · · · · (更多)
1 CODE SHOULD BE EASY TO UNDERSTAND
What Makes Code "Better"?
The Fundamental Theorem of Readability
Is Smaller Always Better?
Does Time—Till—Understanding Conflict with Other Goals?
· · · · · · (更多)
PREFACE
1 CODE SHOULD BE EASY TO UNDERSTAND
What Makes Code "Better"?
The Fundamental Theorem of Readability
Is Smaller Always Better?
Does Time—Till—Understanding Conflict with Other Goals?
The Hard Part
Part One SURFACE—LEVEL IMPROVEMENTS
2 PACKING INFORMATION INTO NAMES
Choose Specific Words
Auoid Generic Names Like Imp and retual
Prefer Concrete Names ouer Abstract Names
Attaching Extra Information to a Name
How Lon.g Should a Name Be?
Use Name Formatting to Conuey Meaning
Summary
3 NAMES THAT CAN'T BE MISCONSTRUED
Example: Filter()
Example: Clip(text, length)
Prefer rain and max for (Inclusiue) Limits
Prefer first and last for Inelusiue Ranges
Prefer herin and end for.Inclusiue/Exclusiue Ranges
Naming Booleans
Matching Expectations of Users
Example: Eualuating Multiple Name Candidates
Summary
4 AESTHETICS
Why Do Aesthetics Matter?
BearranRe Line Breaks to Be Consistent and Compact
Use Methods to Clean Up Irregularity
Use Column Alignment When Helpful
Pick a Meaningful Order, and Use It Consistently
Organize Declarations into Blocks
Break Code into "Parafgraphs"
Personal Style uersus Consistency
Summary
5 KNOWING WHAT TO COMMENT
What NOT to Comment
Becording Your Thouyhts
Put Yourself in the Reader's Shoes
Final Thoughts——Getting Over Writer's Block
Summary
6 MAKING COMMENTS PRECISE AND COMPACT
Keep Comments Compact
Avoid Ambiguous Pronouns
Polish Sloppy Sentences
Describe Function Behavior Precisely
Use Input/Output Examples That Illustrate Corner Cases
State the Intent of Your Code
"Named Function Parameter" Comments
Use Information—Dense Words
Summary
Part Two SIMPLIFYING LOOPS AND LOGIC
7 MAKING CONTROL FLOW EASY TO READ
The Order of Arguments in Conditionals
The Order of if/else Blocks
The ?: Conditional Expression (a.k.a."Ternary Operator")
Avoid dogwhile Loops
Returning Early from a Function
The Infamous goto
Minimize Nesting
Can You Follow the Flow of Execution?
Summary
8 BREAKING DOWN GIANT EXPRESSIONS
Explaining Variables
Summary Variables
Using De Morgan's Laws
Abusing Short—Circuit Logic
Example: Wrestling with Complicated Logic
Breaking Down Giant Statements
Another Creative Way to Simplify Expressions
Summary
9 VARIABLES AND READABILITY
Eliminatinfg Variables
Shrink the Scope of Your Variables
Prefer Write—Once Variables
A Final Example
Summary
Part Three REORGANIZING YOUR CODE
10 EXTRACTING UNRELATED SUBPROBLEMS
Introductory Example: find Closest Loeation()
Pure Utility Code
Other General—Purpose Code
Create a Lot of General—Purpose Code
Project—Specific Functionality
Simplilying an Existing Interface
Reshaping an Interface to Your Needs
Taking Things Too Far
Summary
11 ONETASK ATA TIME
Tasks Can Be Small
Extracting Values from an Object
A Larger Example
Summary
12 TURNING THOUGHTS INTO CODE
Describing Logic Clearly
Knowing Your Libraries Helps
Applying This Method to Larger Problems
Summary
13 WRITING LESS CODE
Don't Bother Implementing That Feature——You Won't Need It
Question and Break Douan Your Requirements
Keeping Your Codebase Small
Be Familiar with the Libraries Around You
Example: Using Unix Tools Instead of Coding
Summary
Part Four SELECTED TOPICS
14 TESTING AND READABILITY
Make Tests Easy to Read and Maintain
What's Wrong with This Test?
Making This Test More Readable
Making Error Messages Readable
Choosing Good Test Inputs
Naming Test Functions
What Was Wrong with That Test?
Test—Friendly Deuelopment
Going Too Far
Summary
15 DESIGNING AND IMPLEMENTING A "MINUTE/HOUR COUNTER"
The Problem
Defining the Class Interface
Attempt 1: A Naiue Solution
Attempt 2: Conueyor Belt Design
Attempt 3: A Time—Bucketed Design
Comparing the Three Solutions
Summary
A FURTHER READING
INDEX
· · · · · · (收起)
1 CODE SHOULD BE EASY TO UNDERSTAND
What Makes Code "Better"?
The Fundamental Theorem of Readability
Is Smaller Always Better?
Does Time—Till—Understanding Conflict with Other Goals?
The Hard Part
Part One SURFACE—LEVEL IMPROVEMENTS
2 PACKING INFORMATION INTO NAMES
Choose Specific Words
Auoid Generic Names Like Imp and retual
Prefer Concrete Names ouer Abstract Names
Attaching Extra Information to a Name
How Lon.g Should a Name Be?
Use Name Formatting to Conuey Meaning
Summary
3 NAMES THAT CAN'T BE MISCONSTRUED
Example: Filter()
Example: Clip(text, length)
Prefer rain and max for (Inclusiue) Limits
Prefer first and last for Inelusiue Ranges
Prefer herin and end for.Inclusiue/Exclusiue Ranges
Naming Booleans
Matching Expectations of Users
Example: Eualuating Multiple Name Candidates
Summary
4 AESTHETICS
Why Do Aesthetics Matter?
BearranRe Line Breaks to Be Consistent and Compact
Use Methods to Clean Up Irregularity
Use Column Alignment When Helpful
Pick a Meaningful Order, and Use It Consistently
Organize Declarations into Blocks
Break Code into "Parafgraphs"
Personal Style uersus Consistency
Summary
5 KNOWING WHAT TO COMMENT
What NOT to Comment
Becording Your Thouyhts
Put Yourself in the Reader's Shoes
Final Thoughts——Getting Over Writer's Block
Summary
6 MAKING COMMENTS PRECISE AND COMPACT
Keep Comments Compact
Avoid Ambiguous Pronouns
Polish Sloppy Sentences
Describe Function Behavior Precisely
Use Input/Output Examples That Illustrate Corner Cases
State the Intent of Your Code
"Named Function Parameter" Comments
Use Information—Dense Words
Summary
Part Two SIMPLIFYING LOOPS AND LOGIC
7 MAKING CONTROL FLOW EASY TO READ
The Order of Arguments in Conditionals
The Order of if/else Blocks
The ?: Conditional Expression (a.k.a."Ternary Operator")
Avoid dogwhile Loops
Returning Early from a Function
The Infamous goto
Minimize Nesting
Can You Follow the Flow of Execution?
Summary
8 BREAKING DOWN GIANT EXPRESSIONS
Explaining Variables
Summary Variables
Using De Morgan's Laws
Abusing Short—Circuit Logic
Example: Wrestling with Complicated Logic
Breaking Down Giant Statements
Another Creative Way to Simplify Expressions
Summary
9 VARIABLES AND READABILITY
Eliminatinfg Variables
Shrink the Scope of Your Variables
Prefer Write—Once Variables
A Final Example
Summary
Part Three REORGANIZING YOUR CODE
10 EXTRACTING UNRELATED SUBPROBLEMS
Introductory Example: find Closest Loeation()
Pure Utility Code
Other General—Purpose Code
Create a Lot of General—Purpose Code
Project—Specific Functionality
Simplilying an Existing Interface
Reshaping an Interface to Your Needs
Taking Things Too Far
Summary
11 ONETASK ATA TIME
Tasks Can Be Small
Extracting Values from an Object
A Larger Example
Summary
12 TURNING THOUGHTS INTO CODE
Describing Logic Clearly
Knowing Your Libraries Helps
Applying This Method to Larger Problems
Summary
13 WRITING LESS CODE
Don't Bother Implementing That Feature——You Won't Need It
Question and Break Douan Your Requirements
Keeping Your Codebase Small
Be Familiar with the Libraries Around You
Example: Using Unix Tools Instead of Coding
Summary
Part Four SELECTED TOPICS
14 TESTING AND READABILITY
Make Tests Easy to Read and Maintain
What's Wrong with This Test?
Making This Test More Readable
Making Error Messages Readable
Choosing Good Test Inputs
Naming Test Functions
What Was Wrong with That Test?
Test—Friendly Deuelopment
Going Too Far
Summary
15 DESIGNING AND IMPLEMENTING A "MINUTE/HOUR COUNTER"
The Problem
Defining the Class Interface
Attempt 1: A Naiue Solution
Attempt 2: Conueyor Belt Design
Attempt 3: A Time—Bucketed Design
Comparing the Three Solutions
Summary
A FURTHER READING
INDEX
· · · · · · (收起)
喜欢读"易读代码的艺术"的人也喜欢 · · · · · ·
易读代码的艺术的书评 · · · · · · ( 全部 34 条 )
代码为什么需要可读?
有一次在code review的时候,一个应届毕业生问我,代码为什么需要可读性。我和他讲代码的美感和优雅、可维护性、可测试性,他却说那有什么用,只要能跑起来,能够实现功能,不就是好代码么?我不能否认这一点,但只能实现功能的代码绝对称不上好代码,就像没杀过人的人就是好人...
(展开)
注重代码质量利国利民
本书主要观点: 1. 优雅的命名 1.1 命名具备自解释性(解释用途) 1.2 能附加(必要的)更多信息(匈牙利命名法的类型信息) 1.3 命名格式统一,如 kConstName 骆驼命名法或单词下划线 bool变量的is, has, can等前缀 ... 1.4 遵循业界的命...
(展开)
确实很多是实践中的体现出来的问题
之前做重构项目的时候,就发现了代码质量的问题,一些老模块的代码写的简直令人发指,没有文档没有任何资料的情况下,只能人肉去读代码梳理功能,经历了各种痛苦,后来也不断在组内各种灌输代码质量的意识,在这方面做了一些推动。 偶然间翻了这本书,感觉一下找到了知己,命名...
(展开)
《The art of readable code》笔记
《The art of readable code》笔记 25 November 2012 前言 入职新公司,接收前任留下的code,觉得有些凌乱,于是乘势带着学习的心态又把整个代码重写了遍。期间又把去年读过的这本书拿过来重读了一遍,这本书举的例子是作者平时的一些总结,作为顶尖互联网公司(Google)的工程师...
(展开)
> 更多书评 34篇
论坛 · · · · · ·
在这本书的论坛里发言这本书的其他版本 · · · · · · ( 全部4 )
-
机械工业出版社 (2012)8.7分 1221人读过
-
O'Reilly Media (2011)8.7分 296人读过
-
オライリージャパン (2012)暂无评分 5人读过
在哪儿借这本书 · · · · · ·
以下书单推荐 · · · · · · ( 全部 )
- Data in-out (花音妙)
- 我读2013 (离线思考)
- 模式与代码优化 (肖文英)
- 2020年书单 (阿斌哥)
- 程序设计 (Gmc2)
谁读这本书? · · · · · ·
二手市场
· · · · · ·
订阅关于易读代码的艺术的评论:
feed: rss 2.0
1 有用 ithan 2018-06-10 15:43:08
初级程序员必读
0 有用 不易放棄的威廉 2015-01-14 20:54:12
a great book that answers my question of what is good code.
0 有用 奶茶加咖啡 2014-08-18 09:50:28
通俗易懂...慢慢学习中
0 有用 邻家の躺平人 2013-05-02 19:33:26
像coding style这种容易被忽略但在编码中有不小影响力的东西值得多了解。
0 有用 wangqi1131 2016-11-01 11:58:43
不错的一本书。
0 有用 御劍風吟 2023-10-12 19:58:31 上海
花了“十年”时间,终于断断续续看完了。经典的编写可读代码的指南,可操作性挺强,美国同事都觉得我基于这本书原则写的code很容易读懂。最喜欢这本书里代码需要让别人看懂,尤其是三个月后的自己这个论断。其他类似讲代码风格和可读性的书也很多,这一本也算是入门且较简洁的一本。
1 有用 Euan 2019-09-29 13:26:56
2.0
1 有用 ithan 2018-06-10 15:43:08
初级程序员必读
0 有用 wangqi1131 2016-11-01 11:58:43
不错的一本书。
0 有用 Willings 2015-08-26 21:52:05
读了英文版,5分。team work/code review必备。