From BookJive
|
|
| Edition: | Prentice Hall (Paperback) |
| Author: | Robert Cecil Martin |
| Published: | August 2008 |
| Pages: | 464 |
| ISBN 10: | 0132350882 |
| New: | $29.20 (33) |
| Used: | $33.45 (21) |
| + add to my profile | |
Chapter 1: Clean Code
'They had rushed the product to market and had made a huge mess in the code. As they added more and more features, the code got worse and worse until they simply could not manage it any longer. It was bad code that brought the company down' (p. 1)
Every programmer has had to wade through bad code at some point. Bad code feeds on itself and becomes worse and worse unless the proper time and resources are spent to reverse the situation or until the project fails. Writing careless code may help meet immediate deadlines, but as time increases and as the mess becomes more complex productivity will eventually come to a near halt as every change of the code breaks two or three other systems.
Bad codes is often blamed on impossible deadlines, poor requirement documentation, changing requirements but the onus of the success or the failure of any software must lie with the programmers. Programmers must take an active role in working out schedules and requirements documents with their managers and with the clients. It is the programmers who are best situated to provide the information needed make critical project decisions.
Clean code is 'pleasingly graceful and stylish in appearance or manner; pleasingly ingenious and simple' (p. 7)
Chapter 2: Meaningful Name
Variable, class, methods, arguments, etc. should all have intent revealings names.
- int d; //elapsed time in days (poor example)
- int elapsedTimeInDays; (good example)
You should never have to use comments to explain a name, if so, the name needs to be changed to something more revealing. If you find a better name take the time to replace it in your code (this isn't as hard as it may sound with the help of modern IDEs).
Name Guidelines:
- Avoid names that mislead (the variable 'l' may look like a '1', names with small differences that are hard to distinguish)
- Avoid using names with useless noise (accountInfo or accountData when account would be fine)
- Use pronounceable names
- Use searchable names
- Don't mentally map ideas and names that make it hard for other programmers to follow
- Class names should be nouns (Customer, WikiPage, etc.) and methods should be verb phrases (postPayment, deletePage, etc.)
- Be consistent in your name meanings (pick one word and use it consistently for the same concept i.e. Manager vs. Controller)
- group variables in a meaningful context by creating a class instead off appending or prefixing
