Target audience: developers
Urs’ comment: A short, simple book about what makes software complex, how to prevent that and therefore keep software simple. This book contains rules and facts about software regarding code simplicity. The problem of the book is that either you probably know most of its content or you think that it doesn’t work anyway (I got this impression while reading through the reviews on Amazon). Anyway, I think it is worth the time and helps to reflect on one’s own way of coding.
I updated my clean code cheat sheet.
This time there are just minor changes:
- Principles: mind-sized components
- Class Design: do stuff or know others, but not both
- Maintainability killers: tangles
- Refactoring patterns: refactor before adding functionality, small refactorings
- removed duplication regarding one test asserts one thing
- TDD principles: Test domain specific languages
- fixed a bug in the ATDD/TDD cycle (run all acceptance tests)
If you miss something or think that there is something just plain wrong, please write a comment below.
Link: Clean Code V2.4
This is the fifth post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.
Your code prevents doing the right thing
I often see teams that want to do the right thing but can’t. Their software won’t let them.
This is caused by lots of loose ends in the source code. Everything is begun but nothing is finished. There are simply too many open tasks. Or there is a lot of technical debt present. Before the team can do what it needs to do, it has to pay back a lot of technical debt. And there is often not the time for that. A third cause is lack of automation. Everything has to be done by hand. This is error prone and slow. And all takes too much time to do it right, so just add a shortcut more to get it done. But this makes things even worse the next time a decision has to be made.
There is an updated version at http://www.planetgeek.ch/2014/11/18/clean-code-cheat-sheet-v-2-4/
It took me about one and a half year to update my cheat sheet about clean code and TDD.
But now, it’s here.
The cheat sheet has grown quite a bit and now contains principles, patterns, smells and guidelines for
- clean code
- class and package design
- TDD – Test Driven Development
- ATDD – Acceptance Test Driven Development
- Continuous Integration
I had to re-layout the sheets because maintenance became a nightmare (yes, very ironic).
Download: Clean Code V2.2
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
Feedback is highly welcome. Please write a comment below.
Update V 2.1: thanks for your feedback
- added + and – for DOs and DONTs to make it easier to tell them apart
- added a creative commons Attribution 3.0 Unported license.
Update V 2.2:
- changed the colours to be better distinguishable
In my current project, we do a lot of refactoring to keep the source code as simple and understandable as possible. This involves a lot of renaming of classes and moving classes between namespaces to structure the code in a better understandable way (here is explained how we structure our code). Sometimes, this results in unit tests not renamed or moved along with the production classes they test.
Therefore, I wrote some NDepend queries that show us these misplaced or misnamed test classes.
cross-post from bbv blog
When software projects grow both in age and size the developers often struggle with the structure of the code. It gets more and more difficult to find the class you have to change for a new requirement. In this post, I’ll show you how we organize our code and how we derive our structure directly from the requirements.
Some time ago, Patrick Smacchia (NDepend lead developer) offered me a NDepend Pro license to play around. NDepend is a tool providing a lot of features. The feature that impressed me from the very start is visualizing dependencies. Not just dependencies from classes to classes, or assemblies to assemblies; no from everything to everything. Like for example all assemblies that use somewhere the method Foo of class Bar. It works for assemblies, namespaces, types, methods and fields.
But, what’s all this fuss about?
Keeping a code base and its design as simple as possible over a long period of time is very difficult. It happens just too quickly that we loose the overview of how things are sticked together. And this is the moment when NDepend with its quick and easy dependency visualization comes to the rescue.
This is the start of a series of posts about Clean Code. I’m going to pick some topics from my cheat sheets about Clean Code and Clean Test Driven Development and explain them in more details.
Today’s topic is
Nested code should be more specific or handle less probable scenarios than unnested code.
Updated: new version here!
I have compiled two cheat sheets about clean code (the ones mentioned in my post about Code Quality!).
The first covers clean code – code that is easy readable and keeps changeable. The second is about Test Driven Development. Both cheat sheets list principles, patterns, practices and smells.
You can download them here – Clean Code Cheat Sheet V1.3, Clean TDD Cheat Sheet V1.2.
Take a look!
I’d like to read your feedback in the comments section…
(just an unreadable preview 🙂 – click on link in text above)
I’m going to speak about code quality (see my short version of the presentation) at the conference BASTA!
BASTA! is mainly focused on .NET technology and gives you the opportunity to see and speak with a wide range of technology experts.
If you have any feedback of what you are missing in my short presentation, please write a comment here or on the post with the presentation. The short version takes about 30 minutes and my speak at BASTA! is scheduled for 1 hour and 15 minutes. I will mainly show real life examples of the theory shown in the short version. But if you want to here something specific, ask for it 🙂
I’ll probably will publish the long version on this blog, too – for all of you not joining the conference.