I have a theory ...

... that methods come in two flavours.

The first flavour is simple. For example, methods like runMessages() consist of an iteration that runs each message. Heck, they might even send run() to each element in a list, but they don't do much else. They are trivial to understand and easy to see working.

Then there are the complex kind. These are the hairy long methods that do interesting work. They might be inlined, access the representation directly and have a ton of local variables and switches. These methods need to be decoded each time you see them.

The assertion is this: If your code is all simple, then control is too decentralized and your program might be large and slow, making it difficult for others to understand, maintain and debug. If your code is all complex, then control is too centralized and your code is a mess, making it difficult for others to understand, maintain and debug.

A good program has the right mix of both.

Steve

Fix only the one place

Like Sergent Pepper's Lonely Hearts Club Band (Reprise), "It's getting pretty near the end" for Eclipse 3.4. As always, there is a stream of bug reports coming in, 99.9% won't get fixed for this release.

We did fix 235219 yesterday (Cheese in tree). It was a regression from 3.3 that had a big visual impact on Eclipse. Amazingly, it was only reported just now. The underlying problem was that the Windows message TVM_GETVISIBLECOUNT returns only the fully visible item count of a tree and we made the mistake of thinking that it included the partially obscured item at the bottom. The fix was to change a "<" to a "<=".

TVM_GETVISIBLECOUNT is used in other places. After a careful analysis, we decided that we wouldn't change them. The code is wrong, but we've done our testing, the impact is low and it's too late. Better to fix only the one place and leave bugs in, than blow the release.

Steve