杨树花满天飘的中午 和二傻吃断了一支楼上楼的筷子


什么是 clean code

最近看到了一本书 Clean Code. 没有耐心读完,但是摘抄其中的几段。
# 以下是原文
What is clean code?

Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language
I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and  performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.

Grady Booch, author of Object Oriented Analysis and Design with Applications
Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.

“Big” Dave Thomas, founder of OTI, godfather of the Eclipse strategy
Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone.

Michael Feathers, author of Working Effectively with Legacy Code
I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to
make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by someone
who cares deeply about the craft.

Ron Jeffries, author of Extreme Programming Installed and Extreme Programming Adventures in C#
Ron began his career programming in Fortran at the Strategic Air Command and has written code in almost every language and on almost every machine. It pays to consider his words carefully.
In recent years I begin, and nearly end, with Beck’s
rules of simple code. In priority order, simple code:
• Runs all the tests;
• Contains no duplication;
• Expresses all the design ideas that are in the system;
• Minimizes the number of entities such as classes, methods, functions, and the like.
Of these, I focus mostly on duplication. When the same thing is done over and over, it’s a sign that there is an idea in our mind that is not well represented in the code. I try to figure out what it is. Then I try to express that idea more clearly. Expressiveness to me includes meaningful names, and I am likely to change the names of things several times before I settle in. With modern coding tools such as Eclipse, renaming is quite inexpensive, so it doesn’t trouble me to change. Expressiveness goes beyond names, however. I also look at whether an object or method is doing more than one thing. If it’s an object, it probably needs to be broken into two or more objects. If it’s a method, I will always use the Extract Method refactoring on it, resulting in one method that says more clearly what it does, and some submethods saying how it is done.
Duplication and expressiveness take me a very long way into what I consider clean code, and improving dirty code with just these two things in mind can make a huge difference. There is, however, one other thing that I’m aware of doing, which is a bit harder to explain.
After years of doing this work, it seems to me that all programs are made up of very similar elements. One example is “find things in a collection.” Whether we have a database of employee records, or a hash map of keys and values, or an array of items of some kind, we often find ourselves wanting a particular item from that collection. When I find that happening, I will often wrap the particular implementation in a more abstract method or class. That gives me a couple of interesting advantages. I can implement the functionality now with something simple, say a hash map, but since now all the references to that search are covered by my little abstraction, I can change the implementation any time I want. I can go forward quickly while preserving my ability to change later.
In addition, the collection abstraction often calls my attention to what’s “really” going on, and keeps me from running down the path of implementing arbitrary collection behavior when all I really need is a few fairly simple ways of finding what I want.
Reduced duplication, high expressiveness, and early building of simple abstractions.
That’s what makes clean code for me.

Ward Cunningham, inventor of Wiki, inventor of Fit, coinventor of eXtreme Programming. Motive force behind Design Patterns. Smalltalk and OO thought leader. The godfather of all those who care about code.
You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.























     后来 ,我发现任何只要是有一点不适的事情都是可以训练的,我们可以将一件不适的事情变成一种习惯,然后你会离不开它,觉得这点小痛苦其实是平淡无奇生活中的一种调味料。这件事由不适变得舒适,良好的习惯就是这样养成的。
















       1、拖延的习惯。我们为什么要拖延,主要原因在于我们要做的事情令我们感到不适。所以,我们的头脑会产生各种各样的借口和诱惑,来促使我们去做更容易的,更舒服的事情。但是,这对我们应该完成的任务没有任何帮助。有的时候,我们甚至会变得急躁和焦虑。这种拖延的习惯从生理上来讲是我们生物的本能——趋向有利刺激,躲避有害刺激。当我们把一件事情定义为“不舒适”的时候,我们会本能的不想去做它,想方设法拖延到明天。为了将这种习惯性的拖延频率降低甚至是消除,我们将要付出很大的痛苦。但是,如果我们能够把这种痛苦分解成1000份,变成可以忍受的程度,那么事情就变得容易了。 我们可以制定一个表格,叫做“战胜拖延”。每次有想要拖延的想法的时候,就立刻去做,完成任务之后就在表格上+1,当完成1000+的时候,拖延的习惯就根除了。