Clean Code

按有用程度 按页码先后 最新笔记

• 

  第101页

  jermaine (开始豆瓣)

  尽量不要返回null值，和传递null值，返回null值使得调用者总是需要去做null值检查，影响了代码的美观以及特殊情况处理和正常流程区分开的原则。而传递异常则更恐怖，接收者不得不去做异常检查。 一些null值的返回传递其实都是一些特殊情况而已，这时候可以考虑尽量将这些特殊情况普通化，在统计应用中，null返回成一个计算值为0的对象等等。如果实在是一个异常而不是特殊情况那么就直接用异常好了。 (更多)

  尽量不要返回null值，和传递null值，返回null值使得调用者总是需要去做null值检查，影响了代码的美观以及特殊情况处理和正常流程区分开的原则。而传递异常则更恐怖，接收者不得不去做异常检查。

  一些null值的返回传递其实都是一些特殊情况而已，这时候可以考虑尽量将这些特殊情况普通化，在统计应用中，null返回成一个计算值为0的对象等等。如果实在是一个异常而不是特殊情况那么就直接用异常好了。 (收起)

  2011-11-24 13:36:02   回应

  收藏

  推荐
• 

  第100页

  jermaine (开始豆瓣)

  应该依调用者的需要来定义异常类，也就是尽量考虑异常应该如何被捕获而不是仅仅说明这个异常是网络异常还是文件访问异常。一些第三方的代码往往会抛出很多第三方定义的异常，由于Java的Checked Exception允许代码在签名处指定可能会抛出异常，因此抛出异常是引入了一些不必要的依赖的，其实为了实现这样一个异常处理，JVM本身也需要做很多诸如栈行走之类的工作。将第三方实现打包总是一个很好的选择，因为这意味着可以将这些第三方... (更多)

  应该依调用者的需要来定义异常类，也就是尽量考虑异常应该如何被捕获而不是仅仅说明这个异常是网络异常还是文件访问异常。一些第三方的代码往往会抛出很多第三方定义的异常，由于Java的Checked Exception允许代码在签名处指定可能会抛出异常，因此抛出异常是引入了一些不必要的依赖的，其实为了实现这样一个异常处理，JVM本身也需要做很多诸如栈行走之类的工作。将第三方实现打包总是一个很好的选择，因为这意味着可以将这些第三方异常变成自己定义的异常，当需要使用另外一个第三方实现时，只要把这些异常换一遍就可以了，不让之上的代码依赖第三方异常，而只依赖自己定义的一个异常。当异常处理的时候再由一个Wrapper去解析就可以了。 (收起)

  2011-11-24 13:31:12   回应

  收藏

  推荐
• 

  第49页

  jermaine (开始豆瓣)

  什么也比不上放置良好的注释来得有用。什么也不会比乱七八糟的注释更有本是搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。 注释并不像辛德勒的名单。他们并不”纯然的好“。实际上，注释最多也就是一种必须的恶。若编程语言足够有表达力，或者我们长于用这些语言来表达意图，就不那么需要注释--也许根本就不需要。 (更多)

  什么也比不上放置良好的注释来得有用。什么也不会比乱七八糟的注释更有本是搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。 注释并不像辛德勒的名单。他们并不”纯然的好“。实际上，注释最多也就是一种必须的恶。若编程语言足够有表达力，或者我们长于用这些语言来表达意图，就不那么需要注释--也许根本就不需要。

  (收起)

  2011-11-17 13:32:46   回应

  收藏

  推荐

• 

  第1页

  nkcfan

  another way to know that a function is doing more than “one thing” is if you can extract another function from it with a name that is not merely a restatement of its implementation (更多)

  another way to know that a function is doing more than “one thing” is if you can extract another function from it with a name that is not merely a restatement of its implementation

  (收起)

  2011-02-06 12:36:56   回应

  收藏

  推荐
• 

  第1页

  jacky.yang

  The Boy Scout of America have a simple rule: "Try and leave this world a little better than you found it". Mr Robert C. Martin, authors of Clean Code, adapted it as The Boy Scout Rule: check-in our code a little cleaner than when we check it out. What we need to do is to write our code firstly, and then to refactor it, it is a continuous improvemnt. From down to top, it is better to ... (更多)

  The Boy Scout of America have a simple rule: "Try and leave this world a little better than you found it".

  Mr Robert C. Martin, authors of Clean Code, adapted it as The Boy Scout Rule: check-in our code a little cleaner than when we check it out. What we need to do is to write our code firstly, and then to refactor it, it is a continuous improvemnt.

  From down to top, it is better to pay attention below items:

  1, Meaningful Names.

  2, Small Functions and less argument.

  3, Good Comments and Bad Comments

  4, Formatting the code.

  5, Object-oriented, expose behavior and hide data, make it easy to add new class without change existing functions; data structure, expose data, make it easy to add new functions wihout changing the existing data structure.

  6, Error Handling code is viewable independently of main code.

  7, Manage third-party boundaries by having few places in the code that refer to them(wrap them, use Adapter).

  8, Keep Unit test clean.

  9, class should be small(single responsibility principle), open-close principle, dependency inversion principle.

  10,separate consturcting a system from using it.(dependency injection)

  11,Emergent Design: Runs all the tests, Refactoring.

  12,Concurrency.

  In fact, there are too many rules, and some rules are also need to be reconsidered and balanced. However, As the author said that: the value system has been the goal and the topic of this book. Professionalism and craftsmanship come from values that drive disciplines. (收起)

  2011-02-13 17:56:44   回应

  收藏

  推荐
• 

  第6页

  jermaine (开始豆瓣)

  糟糕的代码引发混乱！别人修改糟糕的代码是，往往会越改越烂。 好的代码应该让人感觉到作者是在意代码的，代码的任何一点点修改都会让人感到不满。 (更多)

  糟糕的代码引发混乱！别人修改糟糕的代码是，往往会越改越烂。

  好的代码应该让人感觉到作者是在意代码的，代码的任何一点点修改都会让人感到不满。 (收起)

  2011-11-16 13:28:27   回应

  收藏

  推荐

• 

  第101页

  jermaine (开始豆瓣)

  尽量不要返回null值，和传递null值，返回null值使得调用者总是需要去做null值检查，影响了代码的美观以及特殊情况处理和正常流程区分开的原则。而传递异常则更恐怖，接收者不得不去做异常检查。 一些null值的返回传递其实都是一些特殊情况而已，这时候可以考虑尽量将这些特殊情况普通化，在统计应用中，null返回成一个计算值为0的对象等等。如果实在是一个异常而不是特殊情况那么就直接用异常好了。 (更多)

  尽量不要返回null值，和传递null值，返回null值使得调用者总是需要去做null值检查，影响了代码的美观以及特殊情况处理和正常流程区分开的原则。而传递异常则更恐怖，接收者不得不去做异常检查。

  一些null值的返回传递其实都是一些特殊情况而已，这时候可以考虑尽量将这些特殊情况普通化，在统计应用中，null返回成一个计算值为0的对象等等。如果实在是一个异常而不是特殊情况那么就直接用异常好了。 (收起)

  2011-11-24 13:36:02   回应

  收藏

  推荐
• 

  第100页

  jermaine (开始豆瓣)

  应该依调用者的需要来定义异常类，也就是尽量考虑异常应该如何被捕获而不是仅仅说明这个异常是网络异常还是文件访问异常。一些第三方的代码往往会抛出很多第三方定义的异常，由于Java的Checked Exception允许代码在签名处指定可能会抛出异常，因此抛出异常是引入了一些不必要的依赖的，其实为了实现这样一个异常处理，JVM本身也需要做很多诸如栈行走之类的工作。将第三方实现打包总是一个很好的选择，因为这意味着可以将这些第三方... (更多)

  应该依调用者的需要来定义异常类，也就是尽量考虑异常应该如何被捕获而不是仅仅说明这个异常是网络异常还是文件访问异常。一些第三方的代码往往会抛出很多第三方定义的异常，由于Java的Checked Exception允许代码在签名处指定可能会抛出异常，因此抛出异常是引入了一些不必要的依赖的，其实为了实现这样一个异常处理，JVM本身也需要做很多诸如栈行走之类的工作。将第三方实现打包总是一个很好的选择，因为这意味着可以将这些第三方异常变成自己定义的异常，当需要使用另外一个第三方实现时，只要把这些异常换一遍就可以了，不让之上的代码依赖第三方异常，而只依赖自己定义的一个异常。当异常处理的时候再由一个Wrapper去解析就可以了。 (收起)

  2011-11-24 13:31:12   回应

  收藏

  推荐
• 

  第49页

  jermaine (开始豆瓣)

  什么也比不上放置良好的注释来得有用。什么也不会比乱七八糟的注释更有本是搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。 注释并不像辛德勒的名单。他们并不”纯然的好“。实际上，注释最多也就是一种必须的恶。若编程语言足够有表达力，或者我们长于用这些语言来表达意图，就不那么需要注释--也许根本就不需要。 (更多)

  什么也比不上放置良好的注释来得有用。什么也不会比乱七八糟的注释更有本是搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。 注释并不像辛德勒的名单。他们并不”纯然的好“。实际上，注释最多也就是一种必须的恶。若编程语言足够有表达力，或者我们长于用这些语言来表达意图，就不那么需要注释--也许根本就不需要。

  (收起)

  2011-11-17 13:32:46   回应

  收藏

  推荐