clean code meaningful names

---恢复内容开始---

 1 Meaningful Names:

 2 

 3 

 4 use Intention-Revealing Names //nice，Everyone who  reads your code (including you) will be happier if you do.

 5 

 6     The name of a variable, function, or class, should answer all the big questions. It

 7     should tell you why it exists, what it does, and how it is used. If a name requires a com-

 8     ment, then the name does not reveal its intent.//Good Name can help us .

 9 

10     Choosing names that reveal intent can make it much easier to understand and change code 

11 

12 Avoid Disinformation 

13 

14     Programmers must avoid leaving false clues that obscure the meaning of code.We should avoid 
words whose entrenched meanings vary from our intended meaning.

15 

16     Do not refer to a grouping of accounts as an accountList unless it’s actually a List.

17     The word list means something specific to programmers. If the container holding the

18     accounts is not actually a List, it may lead to false conclusions.1 So accountGroup or

19     bunchOfAccounts or just plain accounts would be better.

20 

21 Make Meaningful  Distinctions

22 

23     It is not sufficient to add number series or noise words, even though the compiler is

24     satisfied. If names must be different, then they should also mean something different.

25 

26     In the absence of specific conventions, the variable moneyAmount is indistinguishable

27     from money, customerInfo is indistinguishable from customer, accountData is indistinguish-

28     able from account, and theMessage is indistinguishable from message. Distinguish names in

29     such a way that the reader knows what the differences offer.

30 

31 Use Pronounceable Names

32         

33         Humans are good at words. A significant part of our brains is dedicated to the concept of

34     words. And words are, by definition, pronounceable.

35 

36     In the absence of specific conventions, the variable moneyAmount is indistinguishable

37     from money, customerInfo is indistinguishable from customer, accountData is indistinguishable 

38     from account, and theMessage is indistinguishable from message. Distinguish names in

39     such a way that the reader knows what the differences offer.

40     

41     If you can’t pronounce it, you can’t discuss it without sounding like an idiot. 

42 

43 

44 Use Searchable Names

45 

46     Single-letter names and numeric constants have a particular problem in that they are not

47     easy to locate across a body of text.

48 

49     My personal preference is that single-letter names can ONLY be used as local vari-

50     ables inside short methods

我在项目中大部分都是用的pronounceable names,因为关联的表越来多，涉及到东西也会比较多，名字---见名知意，不仅可以快速的理解代表的含义，也可以知道code的含义或着其目的。

Avoid Encodings



    We have enough encodings to deal with without adding more to our burden. Encoding

    type or scope information into names simply adds an extra burden of deciphering



    Encoded namesare seldom pronounceable and are easy to mis-type.



Hungarian Notation



        So nowadays HN and other forms of type encoding are simply impediments.

    They make it harder to change the name or type of a variable, function, or class. They

    make it harder to read the code. And they create the possibility that the encoding system

    will mislead the reader.



Member Prefixes

        You also don’t need to prefix member variables with m_ anymore. Your classes and func-

    tions should be small enough that you don’t need them. And you should be using an edit-

    ing environment that highlights or colorizes members to make them distinct.



        Besides, people quickly learn to ignore the prefix (or suffix) to see the meaningful

    part of the name. The more we read the code, the less we see the prefixes. Eventually the

    prefixes become unseen clutter and a marker of older code.





Interfaces and Implementations

    These are sometimes a special case for encodings.

    For example, say you are building an ABSTRACT FACTORY for the creation of shapes.

    what should you name them?

        I just want them to know that it’s a ShapeFactory. 

        So if I must encode either the interface or the implementation, I choose

    the implementation. Calling it ShapeFactoryImp, or even the hideous CShapeFactory, 

    is preferable to encoding the interface.





Avoid Mental Mapping



        Readers shouldn’t have to mentally translate your names into other names they already

    know. This problem generally arises from a choice to use neither problem domain terms

    nor solution domain terms.



        This is a problem with single-letter variable names.



        in most other contexts a single-letter name is a poor choice; it’s just a place

    holder that the reader must mentally map to the actual concept. There can be no worse rea-

    son for using the name c than because a and b were already taken.





        One difference between a smart programmer and a professional programmer is that

    the professional understands that clarity is king. Professionals use their powers for good

    and write code that others can understand



Class Names

    

    A class name should not be a verb.



Method Names

        Methods should have verb or verb phrase names like postPayment, deletePage, or save.

    Accessors, mutators, and predicates should be named for their value and prefixed with get,

    set, and is according to the javabean standard.4

    

    For example,

        Complex fulcrumPoint = Complex.FromRealNumber(23.0);

    is generally better than

        Complex fulcrumPoint = new Complex(23.0);



Don’t Be Cute

    If names are too clever, they will be memorable only to people who share the

    author’s sense of humor, and only as long as these people remember the joke.



    Cuteness in code often appears in the form of colloquialisms or slang. For example,

    don’t use the name whack() to mean kill(). Don’t tell little culture-dependent jokes like

    eatMyShorts() to mean abort().

    

    Say what you mean. Mean what you say.



Pick One Word per Concept

    

    Pick one word for one abstract concept and stick with it.

    

         The name leads you to expect two objects that have very different type as well as

    having different classes.

    

         Sadly, you often have to remember

    which company, group, or individual wrote the library or class in order to remember which

    term was used. Otherwise, you spend an awful lot of time browsing through headers and

    previous code samples.



    The function names have to stand alone, and they have to be consistent in order for you to pick the cor-

    rect method without any additional exploration.



    A consistent lexicon is a great boon to the programmers who must use your code.

 

 

---恢复内容结束---