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
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
posted by Steve at
7:35 AM
4 Comments:
Like org.eclipse.swt.browser.Mozilla.create() (rougly 1000 lines of code)? :-]
By
Anonymous, at 4:25 PM
Anony-mouse,
That's hairy. It contains code that is finding XULRunner, managing the initialization of Mozilla, finding XULRunner, checking various versions, hooking listeners, etc. ... and finally creating the browser instance (which takes a ton of code).
Question: Would refactoring it to be simple help?
Steve
By
Steve, at 8:46 AM
Hi Steve,
for a start, it might help factoring out the differences between all those xulrunner versions into different classes.
And I guess it wouldn't really hurt to extract methods like "attachListeners()", "createBrowserInstance()", etc.
Without JDT's "Mark occurrences", it's hardly possible to keep track of all those local variables.
By
Anonymous, at 10:14 AM
> versions into different classes.
Hmmm ... not sure. Factoring out based on versions doesn't seem right to me. Sometimes you need to do a little code here and there based on a version test.
I'm with you on the extract methods thing though.
Stefve
By
Steve, at 1:25 PM
Post a Comment
<< Home