Yet Another Programming Blog

The first look into the contents of the book was a bit scary. Some of these things were already explained in Robert Martin's previous books. Then I found out they are explained from a different (software architect's) perspective. Overall, I liked this book better than Clean Coder, but it was less useful for me than Clean Code book of the same author. Part I - Introduction The foreword contained two useful antipatterns: Too authoritative and rigid architecture. Speculative generality in software architecture. The main point of the preface is that not much changed for the last 50 years in software architecture. The rules of software architecture are the same regardless of any variable (time, type of project, ...). When you get the architecture of the software right, you magically don't need horde of programmers maintaining it. Chapter 1 - What is Design and Architecture? There is no difference between software design and architecture. There is a continuum of

This book's main theme is software developer's professionalism. I like this book much less than Uncle Bob's Clean Code book (the first of the series). That said, it is still a worthy read. Robert C. Martin introduces his book as a catalog of his own errors. He says we are in dire need for professionalism in our software developer profession. Chapter 1 - Professionalism Professionalism is all about taking responsibility. The first rule is to do no harm. As it is virtually impossible to create a bug-free code, the first thing to learn is apologizing. The code has to be tested. Then tested again. The tests must be automated. Basically the QA should find nothing. Uncle Bob demands 100% code coverage by tests. At the very least, your automated tests should assure you that the code will most likely pass the QA. If you find a code which is hard to work with, do the refactoring to make the change easier next time. This is the Boy Scout rule: "Always check in a module clea

These are my personal notes about the Robert C. Martin's book Clean Code. Chapter 2 - Meaningful names The book starts with an advice that we should use intention-revealing names . E.g. elapsedTimeInDays vs d . Of course we should avoid disinformation and non-informative names. Uncle Bob then explains what he means by using meaningful distinctions. E.g. variables message and theMessage next to each other do not make sense. We should obviously use pronounceable names ( generationTimestamp vs genymhdhms ) and searchable names (e.g. MAX_CLASSES_PER_STUDENT is more searchable than 7 ). We shouldn't be cute (e.g. whack method). We should be consistent with names per concept. E.g. decide between fetch , retrieve and get and stick to it.   We should avoid encodings, as the modern programming languages have strong typing, making them unnecessary. E.g. prefix " I " before interfaces names is wrong. Better is no prefix for interfaces and some suffix for implemen