June 2010
3 posts
Why you should write comments before code.
I’ve blogged before that I think the way a developer names blocks of their code says a lot about their experience, not only in a particular platform, but also what they know about the Software Development Life Cycle. But I don’t want to rehash that. Today, I want to talk about when and why to comment. When I create a new class definition, I typically try to add a summary comment right...
The "Named Generic" Anti-pattern
Part One:
When it comes to code, I’m pretty particular about how things are named. To me, naming both classes and class members is one of the fine arts of software development. I actually think that this can demonstrate quite a bit about someone’s experience, what they understand about the software development life cycle, and ultimately, their conceptual understanding of Object-oriented design....
Behaving badly in Public.
One of the key design decisions when writing any code is what level of access you should give each component. In general, my rule of thumb is “As little access as possible.” What this means is that I don’t want to make any class public that doesn’t need to be, and I don’t want to make any members public that are implementation details. In NoRM, we’ve tried to be...
