1. Open closed principle: open for extension, closed for change (Object-Oriented Software Construction by Bertrand Meyer)
2. Tell don’t ask
3. Law of Demeter: Personally, I don’t think this principle can be used steadily nowadays. If you work with frameworks, you seldom have a chance to follow this principle striclty.
4. Continuous Integration: I recommend the article of Martin Fowler for a very good introduction and the Podcast fom se-radio.net For our project, we use Hudson as the continuous integration server.
5. Static code analysis
6. Inversion of Control Container
7. Pass knowledge
8. Measure bugs

1. Interface Segregation Principle: Clients should not be forced to depend upon interfaces that they do not use.
2. Dependency Inversion Principle: a) High level classes should not depend upon low level modules. Both should depend upon abstractions. b) Abstractions should not depend upon details. Details should depend upon abstractions.
3. Liskov Substitution Principle: a) subclasses have to fulfill the invariants of the superclass. Post-conditions of methods in the superclass have to be fulfilled by overriding methods in subclasses.
4. Principles of Least Astonishment: Avoid side-effects. Use, for instance, the command and query separation principle of Bertrand Meyer (Object-Oriented Software Construction).
5. Information Hiding Principle: Well, that’s not a principle, that’s an order
6. Complex Refactorings: See the Refactoring book by Martin Fowler, his Refactoring Web site, or the Refactoring to Patterns book by Joshua Kerievsky.
7. Automated Unit Tests
8. Mockups: For Java I recommend JMockit or mockito.
9. Code Coverage: I recommend Cobertura (free) or Clover (commercial) which both integrate nicely into Hudson.

The new principles of the orange bracelet are:

1. One level of abstraction per method
2. Single responsibility principle (there should never be more than one reason to change a class)
3. Separation of concerns (overlap of functionality between classes should be as little as possible)
4. Coding conventions (Checkstyle ftw!)
5. Use issue tracking
6. Create automated integration tests
7. Read, read, read
8. Review

Yesterday, I received the Clean Code Developer bracelets. Clean Code Developer is an initiative of two German software engineers, Stefan Lieser and Ralf Westphal, to improve software quality in general and source code quality in particular. The foundation of this initiative is the book of our Uncle Bob (Robert C. Martin): “Clean Code.”

To raise the awareness for developing clean code, Stefan and Ralf provide bracelets in different colors. In short, each color represents a particular level of clean code development experience and a certain set of principles to consider in your daily work. That means, you bear a bracelet for 21 days and try for applying the corresponding development principles. After the 21 days you switch the bracelet to the next color, i.e., next level. If you have not been consistent in applying the principles over a day, you should bear the bracelet on the other arm the next day. That should motivate you to apply the principles even more.

Although some of the principles I already use are distributed over different bracelet colors, I started with first level: the red bracelet. Its principles are:

1. Don’t repeat yourself (DRY); one of the pragmatic programmer tips
2. Keep it simple, stupid (KISS)
3. Caution with optimizing code; or à la eXtreme programming: first do it, then do it right, then make it fast
4. Favor composition over inheritance
5. Boy scout rule
6. Root cause analysis
7. Use a version control system
8. Simple refactorings: rename and extract method
9. Reflect your work every day

I encourage you in taking part in the Clean Code Developer initiative. Clean code reflects the passion of the software development craftsmanship. Happy clean coding!

Second, configure a post-commit hook in your Subversion repository: In the repository directory of your Subversion-server, a directory hook exists. In this directory you may already have a file post-commit with 744 permissions. If not, a file post-commit.tmpl exists. In that case, copy the file and change the permissions:

$ cd path/to/your/repository/hook
$ cp post-commit.tmpl post-commit
$ chmod 744 post-commit

To trigger the build via Subversion, just put the following line at the end of the post-commit file.

wget -b http://HUDSON_URL/job/JOB_NAME/build?token=my_automated_build > /dev/null

That’s it.