Clean Code – Chapter 2 (meaningful names)

As I am reading “Clean Code – A Handbook of Agile Software Craftsmanship” by C.Martin, I made some short notes about the contens. I’ve just started reading the book (and I re-read chapter 2 because there was a 2-week time where I didn’t read at all and the areas in my brain about clean code were completely blank) and now I’m somewhere around in chapter 3 but I wanted you to benefit from my reading, so here are my notes (i’ve jsut copy&pasted them from notepad++ to this and I use a ‘#’ to show that this is another bullet point in my list of notes but I hope that this helds nonetheless): #avoid disinformation (the name should exactly explain what the var./class/func. does) and be explicit(!) #no comments to explain what a var/class/func means #use pronouncible names #use searchable names #avoid encodings #the length of a name should correspond to the size of its scope (single-letter names only as local variables and inside short methods #no Hungarian Notation (as in "nameString" –> name contains info about the type) #no silly/unnecessary suf-/prefixes (as m_description –> chop off the "m_") #no special names for interfaces (if necessary use s.th. as "blablablaImp") #class names –> have a Noun or Noun Phrase, avoid "Manager", "Processor", "Data" or "Info" #method names –> verb or verb phrase use JavaBean-Standard naming for Accessors, mutators and predicates #if constructors are overloaded, use static factory methods with names that describe ARGUMENTS #enforce using static factory methods by using private constructor (why?) #pic one word per concept & stick to it (ex. getters always are named "get…") #no puns –> no word/phrase used in different contexts -> ex. it would be consistent to call a mthod that appends something "add", because it adds something, but it should be as explicit and so you should use "append" instead of "add" #use solution domains –> if you use the "delegate"-pattern, use the term "delegate" in the method name to point out that the mthod uses the delegate-pattern #otherwise: use problem domain name #provide a clear context for the variables (make sure everybody gets what they mean and are about –> the class name puts variables in clear context, if no class, consider to use prefix #shorter names are better names in 3 words: –> precision, clearity, explicity Information in English about the Cleant Code Development-Initiative can be found here. An alle, die sich vielleicht wundern, weshalb ich hier auf Englisch schreibe: das Buch ist auf Englisch, weshalb ich eine Notizen auch auf Englisch mache. Außerdem sollte jeder Programmierer/Consultant/Whatever sowieso Englisch können, und wieso sollen nur Deutsch sprechende Menschen von meinen Notizen profitieren?! Weitere Infos zu Clean Code gibt es auf der Website von “Clean Code Development”

Continue reading …