On Sun, Apr 13, 2003 at 03:26:20PM +0200, Stephane Ducasse wrote:
> Hi marcus
> 
> I have a question regarding the second refactorings. I was always 
> hesitating about changing the code like that because of lack of clear 
> idea ;)
> 
The idea is: "If there's a way to express something with less code
more clearly, do it". Nothing else. 

This helps a) readability and b) should be even less buggier (you need
code for bugs, so less code that at the same time communicates more
clearly will not introduce new bugs, but most likely reduce bugs)

This is very much like using "isEmpty" instead of "size = 0".

Of Course, you could ask: Why bother with such trivial stuff? We
have BIG PROBLEMS, let's do them them first.

The answer is simple: "Refactor the low hanging fruit". If you can't
get trivial stuff done, how can you even think about doing the big
refactorings?

A BigRefactorings dialog:

 SuperEgo: This is never going to work the code is a BigBallOfMud and
 everything smells. I need to analyze all this HighLevelArchitecture and
 develop a careful strategy for it.

 Id: Refactor the low-hanging fruit.

 SuperEgo: But the other architects will laugh at me if they see my code
 doesn't have a BigPicture in it.

 Id: Refactor the low-hanging fruit.
 
 .....

See http://c2.com/cgi/wiki?RefactorLowHangingFruit

> 
> Now for == nil ifFalse I do not know. I always have the impression 
> (Wrong I guess too) that for really small images this could have 
> incident but I'm not sure because inlining a method instead of calling 
> it will certainly take more space.
> 
Yes, those refactorings make the code smaller. And this is good.

There could be performance-implications. But we shouldn't optimize
before we know that it is needed. (And then: either a) fix
the system or b) hack around it in the spacial case where it is needed
and DOCUMENT it)
 
For ifNil, someone allready did a): The whole ifNil: logic is actually 
inlined by the compiler...

   Marcus 

-- 
Marcus Denker marcus at ira.uka.de  -- Squeak! http://squeak.de