Last year I went on what can be called an “extended rant”, describing what I believe are Twelve Principles of Good Software Design.
I’ve abstracted the posts in the order they are intended to be read here.
I started my series of posts about my 12 principles of good software design in part as a criticism of the various software practices I’ve seen while writing software, and in part as a prescription for a possible answer to help developers write better code.
I know this sounds arrogant. But after nearly 28 years of writing software, I’ve seen quite a bit. I’ve seen a software team where developers were encouraged to “refactor” their code, which featured what should have been three or four methods turned into a 20-class library, with layers on layers of layers of “refactoring” piled on top. (My refactoring? Spending a week understanding the code, then rewriting it into a single four method class.)
… With that said, here are 12 principles for good idioms–good ways to reorganize or simplify your code. (With all due respect to Dieter Rams’ ten principles for good design.)
- An idiom should make your code simpler.
- An idiom should make your code concise.
- An idiom should make the intent of your code clear.
- An idiom should make your code easier to read.
- An idiom should be unobtrusive and not clever.
- An idiom should help isolate functionality into well defined components.
- An idiom should stick to language features which make code obvious.
- An idiom should keep related functionality together in the same place.
- An idiom should be debuggable.
- An idiom should not require extraordinary steps to compile or break the existing development tool set.
- An idiom should only implement the functionality needed.
- An idiom should allow a new developer to understand the code.
At some point I intend to rewrite this in the form of a book, because I still think it needs to be said.