Code that needs some love/refactoring

[Adriaan de Groot]

On Monday 09 March 2009 20:13:55 nik wrote:
> I'm new to KDE Development. Reading some books about Code Refactoring
> and Design Patterns, I'm interested in code that needs some love :)

Welcome to the club. I suppose you're looking to apply, experimentally, some 
ideas about refactoring?

> For example code that works but is difficult to read/understand and
> therefore could need some restructuring. Simple examples are:
>
>     - big classes that have to much behaviour/methods
>     - long methods
>     - complicated logic that could be clearer by splitting it up
>     - bad names
>     - a source (directory) tree that could be better organized

All typical anti-patterns, yes -- and somewhat subjective, so you will find a 
wide range of conventions and considerations in the KDE code. 

> Now, don't point me to file xyz.cpp and class FooBar. I'm wondering if
> there is some infrastructure for this since I didn't find it. 

You have roughly described the original idea for the KDE quality teams -- 
small improvements that are collected, documented and offered to new 
developers as a way to dive in. Certainly refactoring is something that has a 
pretty well-defined "success" measure. This garnered almost exactly zero 
response. Specifically for doing organising, there's a need to interact with 
the maintainers and sticking with something that makes sense to them as well: 
remember that refactoring / shuffling has a cost.

> A place,
> where some experienced kde developers points other (new) interested
> developers to such code. Just a list of files with some remarks...like
> "Hey, if you are going to work on these files, consider to refactor some
> things..."

No, we do not have such a catalogue. It might be interesting to detect such 
places automatically in some fashion ("show me all methods with a gcc-inliner 
size measure > 200000" for instance), but there's no kept-by-hand list.


> Maybe there could be some section for each project at
> http://techbase.kde.org/Projects . Or just one big page with a table for
> all affected files/classes.

Could be. I see maintainence of the lists as the big challenge: the payoff is 
rather uncertain.


> Changing code is always risky since new bugs can be introduced. Because
> of this it's necessary to write tests before the refactoring. And hey,
> tests are a good thing, right?

Yes. Certainly. Show me a first year CS student who wants to write tests 
first, and code later and .. well, I'll do something embarrassing at Akademy 
this year (I do that *anyway* so this is hardly an incentive).


-- 
Adriaan de Groot - KDE Quality Team, KDE-Solaris
                 - http://www.englishbreakfastnetwork.org/
                 - http://solaris.kde.org/