Agile Otter Blog

I simply hate #regions. Apparently I'm not alone. In C#, a bit of code surrounded in #region...#endregion markers is folded shut by any decent IDE. The code becomes invisible until you ask to see it. This sounds like a good idea, but it really is not. It makes code *look* smaller, but the code is not smaller. It is more of a girdle than a diet. The code is instead better-hidden, an attribute I can hardly describe as a virtue. There are plenty of reasons to hate long methods and long classes. The foremost is that you cannot see and grok them at a single glance. The programmer needs to read code quickly without misunderstanding it. The #region tag is one of the most sure-fire ways to make that problem considerably worse. The region worsens most of the problems long classes and long methods cause. The #region is almost certainly an American or British policy decision. It makes things seem better while all the time making them considerably worse. Whenever we prefer 'seeming...

If you cannot name something well, then please name it appallingly badly. No, this is not a joke about the iPad. When I am stuck for a name, the problem usually not my command of English or lack of a good Thesaurus. It is that either I don't know what kind of a thing I'm applying the name to, or it is in the midst of morphing from one kind of thing into another. In such cases, neither can my pair programming partner name it. Its identity is unclear. Yes, this is about the Single Responsibility Principle again. A class with a clear single responsibility (does it all, does it well, does it only) is easy to name. Anything with a responsibility that is not clear, not complete, or is mixed with other responsibilities is going to be hard to name. Anything that can't have a good name should have a bad name. A very bad name. Most of the rules still apply. You want something greppable, something that isn't going to disinform, and something that is pronounceable (etc). What ...