rednight

0x2B|~0x2B,That's not a question,Just do it.
posts - 32, comments - 14, trackbacks - 0, articles - 0

一本书的目录

Posted on 2006-08-26 10:44 rednight 阅读(204) 评论(0)  编辑  收藏

设计过程

1 编程的本质是:没有意外,最小化耦合,最大化内聚

2 根除复杂性这个恶魔(Part 1)

2.1 不要解决不存在的问题
2.2 解决一个问题,而不要解决一类问题

3 A user interface should not look like a computer program (the transparency principle)

3 用户接口看起来不应该象一个计算机程序(透明原则)
4 Don't confuse ease of learning with ease of use

4 不要混淆易于使用和易于掌握这两个概念
5 Productivity can be measured in the number of keystrokes

5 生产率可以通过击键次数来衡量
6 If you can't say it in English, you can't say it in C/C++

6 如果你不能用自然语言表达,也就不能用C/C++表达
6.1 Do the comments first

6.1 先写注释
7 Read code

7 阅读代码

7.1 There's no room for prima donnas in a contemporary programming shop

8 Decompose complex problems into smaller tasks

8 将复杂的问题分解为多个小任务
9 Use the whole language (Use the appropriate tool for the job)
10 A problem must be thought through before it can be solved

10 解决问题之前应该深思熟虑
11 Computer programming is a service industry

11 计算机编程是服务行业
12 Involve users in the development process

12 开发过程应该有用户参与
13 The customer is always right

13 客户永远是正确的
14 Small is Beautiful. (Big == slow)

14 小即是美(大==慢)

一般开发问题

15 First, do no harm

15 第一,不要有害
16 Edit your code

16 编辑你的代码
17 A program must be written at least twice

17 一个程序应该至少写两次
18 You can't measure productivity by volume

18 不能用代码量衡量生产率
19 You can't program in isolation

19 编程不能与世隔绝
20 Goof off

20 别把编程太当回事
21 Write code with maintenance in mind梩he maintenance programmer is you

21 写代码的时候应该时刻想着维护,假设你自己就是维护者

21.1 Efficiency is often a bugaboo

21.1 追求效率往往导致其它问题

格式化和文档

22 Uncommented code has no value

22 没有注释的代码没有价值
23 Put the code and the documentation in the same place

23 将代码和文档放在一起
24 Comments should be sentences

24 注释应该是完整的句子
25 Run your code through a spelling checker

25 你的代码应该能通过拼写检查
26 A comment shouldn't restate the obvious

26 不要注释显而易见的东西
27 A comment should provide only information needed for maintenance

27 注释中应该只提供对维护有帮助的内容
28 Comments should be in blocks

28 使用块注释
29 Comments should align vertically

29 注释应该垂直对齐
30 Use neat columns as much as possible

30 代码应该尽可能的整齐的分列
31 Don't put comments between the function name and the open brace

31 不要在函数名和第一个花括号之间写注释
32 Mark the ends of long compound statements with something reasonable

32 在较长的代码块之后做标记性注释
33 Put only one statement per line

33 每行只写一条语句
34 Put argument names in function prototypes

34 函数原型中应该写上参数名
35 Use a 損redicate?form to split up long expressions
36 A subroutine should fit on a screen

36 一个子函数的长度应该在一屏以内
37 All code should be printable

37 所有的代码都应该是可打印的
38 Use lines of dashes for visual separation between subroutines

38 使用整行连字符来隔离子函数代码
39 White space is one of the most effective comments

39 空白是最好的注释之一
40 Use four-space indents

40 使用四个空格做缩进
41 Indent statements associated with a flow-control statement

41 缩进所有与一个流程控制语句相关的语句

41.1.Comments should be at the same indent level as the surrounding code

41.1 注释应该与其对应的代码一同缩进

42 Align braces vertically at the outer level

42 在外层垂直对齐花括号
43 Use braces when more than one line is present under a flow-control statement

43 在流程控制语句下面如果有多于一条的语句,应该使用花括号

名字和标识

44 Names should be common English words, descriptive of what the function, argument, or
variable does

44 名字应该是普通英文单词,用来描述这个函数、参数或者变量的作用

44.1.Do not clutter names with gibberish

44.1 不要乱起名字(无意义的,深奥的,不贴切的)

45 Macro names should be ENTIRELY_CAPITALIZED

45 宏名字应该形如:ENTIRELY_CAPITALIZED

45.1 Do not capitalize members of an enum

45.1 不要将枚举类型成员大写
45.2 Do not capitalize type names created with a typedef

45.2 不要将用typedef定义的类型大写

46 Avoid the ANSI C name space

46 避免ANSI C名字空间
47 Avoid the Microsoft name space

47 避免微软名字空间
48 Avoid unnecessary symbols

48避免不必要的符号
49 Symbolic constants for Boolean values are rarely necessary

49 布尔型符号常量基本上没有用

一般编程原则

50 Don't confuse familiarity with readability

50 熟悉代码与代码的可读性好是两回事
51 A function should do only one thing

51 一个函数只应该完成一件事
52 Too many levels of abstraction or encapsulation are as bad as too few

52 过多或者过少的抽象或者封装层次都不好
53 A function should be called more than once, but?br>

53 一个函数应该被多处调用

53.1 Code used more than once should be put into a function

53.1 在多于一处使用的代码应该变成一个函数

54 A function should have only one exit point

54 一个函数应该只有一个退出点

54.1 Always put a return at the outer level

54.1 总是在外层放一个return

55 Avoid duplication of effort

55 避免费两遍事的事情
56 Don't corrupt the global name space

56 不要污染全局名字空间

56.1 Avoid global symbols

56.1 避免全局符号
56.2 Never require initialization of a global variable to call a function

56.2 对函数的调用不应该依赖全局变量是否被初始化

56.2.1 Make locals static in recursive functions if the value doesn't span a recursive call

56.2.1 在第归函数中,如果一个变量与第归调用无关,则其应该是局部静态变量

56.3 Use instance counts in place of initialization functions

56.3 在初始化函数中使用实例计数
56.4 If an if ends in return, don't use else

56.4 如果if语句中有return,则不要再写else

57 Put the shortest clause of an if/else on top

57 最短的if/else子句在最上面
58 Try to move errors from run time to compile time

58 尽量将运行时刻的错误提前到编译时刻
59 Use C function pointers as selectors

59 使用C 函数指针作为选择器
60 Avoid do/while loops

60 避免do/while循环

60.1 Never use a do/while for a forever loop

60.1 不要用do/while实现无限循环

61 Counting loops should count down if possible

61 循环计数应该从大到小
62 Don't do the same thing in two ways at the same time

62 在同一时间不要用不同的方法完成同一件事
63 Use for if any two of an initialization, test, or increment are present

63 如果初始化、测试、增量三者有两个,就应该用for语句
64 If it doesn't appear in the test, it shouldn't appear in the other parts of for statement

64 没有在for语句的测试部分出现的变量,也不应该出现在其他两个部分
65 Assume that things will go wrong

65 总是假定事情要出错
66 Computers do not know mathematics

66 计算机不懂得数学

66.1 Expect the impossible

66.1 总是会出现不可能的事情
66.2 Always check error-return codes

66.2 检查错误返回代码

67 Avoid explicit temporary variables

67 避免显式临时变量
68 No magic numbers

68 不要出现纯数字
69 Make no assumptions about sizes

69 不要对size做假定
70 Beware of casts (C issues)

70 对类型转换要小心(C语言问题)
71 Handle special cases directly

71 立即处理特殊情况
72 Don't try to make lint happy

72 用不着试图让lint不报告问题
73 Put memory allocation and deallocation code in the same place

73 分配内存和释放内存应该在一起
74 Heap memory is expensive

74 堆内存是昂贵的
75 Test routines should not be interactive

75 测试过程不应该是交互的
76 An error message should tell the user what's right

76 错误信息应该告诉用户什么是正确的
77 Don't print error messages if an error is recoverable

77 如果一个错误是可恢复的,就不要打印错误信息
78 Don't use system-dependent functions for error messages

78 不要在错误信息中使用系统相关的函数

预处理器

79 Everything in a .h file should be used in at least two .c files

79 任何出现在头文件的东西都应该在至少两个.c文件中被使用
80 Use nested #includes

80 使用嵌套的#include
81 You should always be able to replace a macro with a function

81 你应该总是可以用函数代替一个宏

81.1 ?: is not the same as if/else

81.1 ?: 并不等同于if/else
81.2 Parenthesize macro bodies and arguments

81.2 在宏定义的body和参数外都应该加上()

82 enum and const are better than a macro

82 枚举和常量都比宏好
83 A parameterized-macro argument should not appear more than once on the right-hand side

83 参数化的宏的参数不能作为右值在宏中出现一次以上

83.1 Never use macros for character constants

83.1 永远不要用宏来表示字符常量

84 When all else fails, use the preprocessor
84 如果所有的else都失败了,使用预处理器

C语言相关原则

85 Stamp out the demons of complexity (Part 2)

85 根除复杂性的恶魔(Part 2)

85.1 Eliminate clutter.

85.1 消除混乱
85.2 Avoid bitwise masks; use bit fields

85.2 避免位掩码,使用位域
85.3 Don't use done flags

85.3 不要使用完成标志
85.4 Assume that your reader knows C

85.4 假设你的读者懂C语言
85.5 Don't pretend that C supports a Boolean type (#define TRUE)

85.5 不要让C语言假装支持布尔类型(#define TRUE)

86 1-bit bit fields should be unsigned

86 1位的位域应该是无符号的
87 Pointers must be above the base address of an array
88 Use pointers instead of array indexes

88 使用指针而不要使用数组索引
89 Avoid goto except . . .

89 避免使用goto,除非...

OO编程/设计(C++和Java)

90 Object-oriented and 搒tructured" designs don't mix

90 不要混合面向对象的设计和结构化的设计

90.1 If it's not object-oriented, use C

90.1 如果不是面向对象的,就用C语言

91 Expect to spend more time in design and less in development

91 在设计上多花些时间,在开发上少花些时间
92 C++ class libraries usually can't be used in a naive way

92 C++类库通常不能没有实验就使用
93 Use checklists

93 使用checklist
94 Messages should exercise capabilities, not request information

94 消息应该用做完成动作,而不是请求信息
95 You usually cannot convert an existing structured program to object-oriented

95 通常不能将结构化的程序转化为面向对象的程序
96 A derived class object is a base-class object

96 派生类的对象是基类对象
97 Derivation is the process of adding member data and methods

97 派生是增加成员数据和方法的过程
98 Design the objects first

98 首先设计对象
99 Design the hierarchy next, from the bottom up

99 然后从下向上的设计类层次

99.1 Base classes should have more than one derived class

99.1 基类应该有多于一个派生类

100 The capabilities defined in the base class should be used by all derived classes

100 基类定义的功能应该能被所有派生类使用
101 C++ is not Smalltalk梐void a common object class

101 C++不是Smalltalk,应该避免公共对象类
102 Mix-ins shouldn't derive from anything in C++, in Java there's no problem if you follow the next rule:


103 Mix-ins should be C++ virtual base classes (in Java they should be interfaces)
104 Initialize virtual base classes with the default constructor

104 用缺省构造函数初始化虚基类
105 Derivation is not appropriate if you never send a base-class message to a derived-class object

105 如果没有从基类向派生类的消息,则派生是不适合的
106 Choose containment over derivation whenever possible
107 Use private base classes only when you must provide virtual overrides (C++ only)
108 Design the data structures last

108 最后设计数据结构
109 All data in a class definition must be private

109 类中的所有数据都必须是私有的
110 Never provide public access to private data

110 从不提供对私有数据的公共访问方法
110.1 Do not use get/set functions

110.1 不要用get/set函数
111 Give up on C idioms when coding in C++

111 在使用C++的时候放弃C语言惯用语
112 Design with derivation in mind

112 设计的时候想着派生
112.1 A member function should usually use the private data of a class

112.1 成员函数应该通常使用私有数据
113 Use const (final in Java)

113 使用常量
114 Use struct only if everything's public and there are no member functions (C++ only)

114 只在所有成员都是公有并且没有成员函数的时候使用结构(只针对C++)
115 Don't put function bodies into class definitions (C++ only)

115 不要将函数体放到类定义中(只针对C++)
116 Avoid function overloads and default arguments

116 避免函数重载和缺省参数
117 Avoid friend classes (in Java, don't use package access.)

117 避免友元(对于Java,不要使用package access)
118 Inheritance is a form of coupling

118 继承是耦合的形式之一
119 Don't corrupt the global name space

119 不要污染全局名字空间

C++ RulesC++原则

References引用

120 Reference arguments should always be const

120 作为参数的引用应该是const
121 Never use references as outputs, use pointers

121 不要用引用作为返回值,使用指针
122 Do not return references (or pointers) to local variables

122 不要返回局部变量的引用(或者指针)
123 Do not return references to memory that came from new

123 不要返回由new分配的内存的引用

Constructors, Destructors, and operator=()构造函数,析构函数和赋值操作符

124 Operator=() should return a const reference

124 =操作符应该返回一个const引用
125 Assignment to self must work

125 赋值给自己必须是可以的
126 Classes having pointer members should always define a copy constructor and operator=()

126 有指针类型成员的类通常应该定义拷贝构造函数和=操作符
127 If you can access an object, it has been initialized

127 如果你可以访问一个对象,它就应该是已经被初始化了的
128 Use member-initialization lists

128 使用成员初始化列表
129 Assume that members and base classes are initialized in random order

129 假设成员和基类是按照随机的顺序被初始化的
130 Copy constructors must use member initialization lists

130 拷贝构造函数必须使用成员初始化列表
131 Derived classes should usually define a copy constructor and operator=()

131 派生类通常应该定义一个拷贝构造函数和=操作符
132 Constructors not suitable for type conversion should have two or more arguments

132 不适合进行类型转化的构造函数应该有两个以上的参数
133 Use instance counts for class-level initialization

133 在class级的初始化中使用实例计数
134 Avoid two-part initialization

134 避免两部分初始化
135 C++ wrappers around existing interfaces rarely work well

Virtual Functions虚函数

136 Virtual functions are those functions that you can't write at the base-class level

136 虚函数是那种不能在基类实现的函数
137 A virtual function isn't virtual when called from a constructor or destructor

137 在构造或者析构函数中,虚函数会失去virtual的特性
138 Do not call pure virtual functions from constructors

138 不要在构造函数中调用纯虚函数
139 Destructors should always be virtual

139 析构函数应该总是virtual的
140 Base-class functions that have the same name as derived-class functions generally should be virtual

140 基类中于派生类同名的函数通常应该是virtual的
141 Don't make a function virtual unless you want the derived class to get control of it

141 不要将函数定义为virtual,除非你希望派生类可以控制它
142 protected functions should usually be virtual

142 保护的成员函数通常都应该是virtual的
143 Beware of casts: C++ issues

143 小心类型转换:C++问题
144 Don't call constructors from operator=()

144 不要在=操作符中调用构造函数

Operator Overloads操作符重载

145 An operator is an abbreviation (no surprises)

145 操作符实际上是函数的缩写方式(不要惊讶)
146 Use operator overloads only to define operations for which there is a C analog (no surprises)

146 只有在存在一个C语言相似物的时候,才应该重载操作符
147 Once you overload an operation, you must overload all similar operations

147 一旦你重载了一个操作,你必须重载所有相似的操作
148 Operator overloads should work exactly like they would in C

148 操作符重载后必须可以象在C中一样使用
149 It's best for a binary-operator overload to be an inline alias for a cast
150 Don't go bonkers with type-conversion operators

150 不要过多的使用类型转换操作符
151 Do all type conversions with constructors if possible

151 尽量在构造函数中完成类型转换

Memory Management

152 Use new/delete rather than malloc()/free()

152 使用new/delete而不要使用malloc()/free()
153 All memory allocated in a constructor should be freed in the destructor

153 所有在构造函数中分配的内存都应该在析构函数中释放
154 Local overloads of new and delete are dangerous

154 重载局部的new/delete操作符是非常危险的

Templates模版

155 Use inline function templates instead of parameterized macros

155 使用inline函数模版而不要用参数化的宏
156 Always be aware of the size of the expanded template

156 总是注意扩展模版的大小
157 Class templates should usually define derived classes

157 类模版通常应该定义派生类
158 Templates do not replace derivation; they automate it

158 模版不能代替继承,它实际上是自动继承的

Exceptions

159 Intend for exceptions not to be caught

159
160 Throw error objects when possible

160 如果可能,尽量抛出错误对象
161 Throwing exceptions from constructors is tricky

161 可以从构造函数中抛出异常


只有注册用户登录后才能发表评论。


网站导航: