I want to bring you attention to an excellent book about the “craft of programming”. It is called “Clean Code” by Robert C Martin. Actually this book is a collaboration of a number of authors who contributed to make a set of rules to live by when coding. I have to say that all the rules they give make a whole lot of sense, one of the best, and most sensible collections of coding rules I have seen in many years. It covers guidelines for code structure, vertical and horizontal formatting, variable naming, class structure, method structure, data structure, test driven development, and many more topics.
I strongly recommend that if you are interested in learning the most recent, well accepted principles in the programming craft, please read this book for guidance. It will help the quality of our projects tremendously.
Title: Clean Code
Author: Robert C Martin
Publisher: Prentice Hall
Avoid the inclusion of “content-free java-doc”. This means that a Java-Doc header is created that has no information content in there. Comments in general should have useful information that is not obvious, or there should be no comment at all. Continue reading
My goals for this “Agile Software Craftsmanship” blog are modest: this is a place to put all the random bits of guidance and advice about software engineering that I collect, organize, and wish to make available to others. Mostly this is aimed at people I work with, as a place they can go to find helpful advice, but if others find this useful that is fine as well.
In 30 of software leadership, I continually run across patterns of behavior in software engineering. Some patterns are good and should be encouraged, while other patterns are bad and need to be stopped. Over the years I have maintained collections of such descriptions. During that time I have put together a couple of books which I have used in managing teams. But the technology keeps changing so fast, it is hard to keep a physical book up to date. I am hoping I can transfer much of that material to blog form, so it is both more readily available, as well as easier for me to maintain. Furthermore, I appreciate the comments that help me make the material better. I might eventually but these together into a published collection at some time, or I might simply rely on the blog.
In many cases I want to engage others in discussions on a forum, but these situations are often complex, and need to be carefully described, and it is hard to get the space in a forum to set up the discussion. I am hoping that the blog will allow the space to lay out the situation, and these posts will then preserved that conclusion as well.
I want to keep this blog separate from my “Collaborative Planning” blog. That other blog is intended to discuss how business people in a organization collaborate to achieve results without programming anything. I fear that mixing the information about programming together would lead to confusion. This blog is about programmers and how to write excellent code. That blog is about organization and management in all fields.
I expect that the first 20 or 30 posts will be material that I have collected in the past, and need simply a place to be stored. After that I hope to explore software craftsmanship issues that I encounter in my job of leading software development teams.
Wish me luck!