~pperalta

In the first talk that I attended today, Uncle Bob makes a convincing argument that time constraints are not an excuse for sloppy coding. His claim is that bad code has a “more profound and long-term degrading effect” than anything else, including bad schedules, requirements, and even team dynamics. He states that coding clean will actually speed up development, especially when you have to go back and make changes. The code sample that he presented was a condensed version of this article that he wrote about a command line argument parser. He starts out by writing code to parse boolean arguments, but his initial design ends up not scaling very well when he adds processing of integer and string arguments. We saw lots of if/then/else statements that were doing type checking. When you see this in an OO language, that’s a good sign that an object hierarchy is in order. The slides show him adding a hierarchy to replace the if/then/else statements with polymorphism, along with some other code cleanup. Here are some tips that he passed along:

• Write code (and tests) in tiny increments.
• Functions should be small. He asked the audience how big a method should be, and an audience member suggested that it should fit within your screen. That would have been my answer as well, but he pointed out that screens are so large (and high res) today that this old rule of thumb doesn’t apply anymore. The limit should be about 20 lines or so.
• A method name should describe exactly what the method does. If you have to browse to the method to figure out what it’s doing, that may be a bad sign.
• Use the Command Query Separation principle. Methods that return a value should not change state, and methods that return void should be used for changing state.

Both in this talk and the Compleat Agile developer, he talks about the allure and dangers of complete rewrites as a remedy for ugly code bases. This is a topic that I have read about before from Joel. In addition to all of the reasons that Joel gives, Uncle Bob provides another one. He has seen elite groups formed in many places to rewrite software only to discover that they cannot keep up with the legacy systems that are still being maintained. Eventually the new system becomes just as much of a mess as the old system. The team tasked with the redesign starts to loose members. Before long, developers are demanding that the new system be redesigned yet again!

Ken Pugh of Pugh-Killeen Associates presented guidelines for creating interfaces:

• An interface implementation shall do what its method says it does. This principle was also mentioned in the clean code talk.
• An interface implementation shall do no harm. This means no nasty side effects, such as memory leaks, etc.
• If an implementation is unable to perform its responsibilities, it shall notify its caller and report an error in the user’s terms, not the implementation terms. This one is important because many times methods will throw internal exceptions that the caller has no idea what to do with.

Tomorrow I’ll get to see Scott Ambler talk about ORM.