Code Formatting
Here are a few of the key code formatting patterns we use. The names and some of the examples are from Kent’s book.
March 23, 1998
Categories:
Practices
Archive for March, 1998
March 23, 1998
Categories:
Practices
Coding Standards
We all code to the exact same standards. We name our classes and methods the same way, we format code the same way.
March 23, 1998
Categories:
Practices
Method comments
In general, we do not comment our methods. Beck teaches that a comment is used to indicate that a method is not yet finished. That’s how we use them.
March 23, 1998
Categories:
Practices
Class comments
We do use class comments to describe what a class is for, and sometimes how it works. We probably don’t do this often enough, and we probably don’t keep them as up to date as we should.
March 23, 1998
Categories:
Practices
Continuous Integration, Relentless Testing
We call the combination of frequent release with tests at 100%: continuous integration, relentless testing. The result is rapid progress and a system that always works better than it did the day before.
March 23, 1998
Categories:
Practices
CRC Card Design
We use CRC card design almost exclusively. Developers, managers, and users are all comfortable with the cards, since they are non-threatening. Moving the cards around makes it easy to describe how classes work, and it is easy to throw a couple of cards away and create new ones if the design isn’t working out.
March 23, 1998
Categories:
Practices
Don’t Go Dark
A few times during the project, a team took on a task and did not complete it within the iteration. They wanted to complete the task and kept it for the next iteration. This generally turned out to be a mistake.
March 23, 1998
Categories:
Practices
Software Documentation
There is some written documentation for the software, more commonly interpreting requirements than documenting design. Sometimes we document an approach to some particularly difficult area. We “never” document code.
