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”