Code that needs some love/refactoring

[klebezettel]

Hiya!

I'm new to KDE Development. Reading some books about Code Refactoring
and Design Patterns, I'm interested in code that needs some love :)

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

Don't get me wrong. I don't want people starting to blame each other.  
It's nothing special that code declines with time. Somebody designs,
then there is a change here and there and after a time you notice that
the initial design is outdated because all the small changes together
does not support the design.  Things work, never mind? Well, every (new)
change needs understanding of the code. If the code is well
structured/designed then it's easy for the (new) developer to become
acquainted with it. As a result, it's easy to fix bugs and implement new
features.

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. 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..."

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.

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?

Just an idea. Any Comments?
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality

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/
_______________________________________________
kde-quality mailing list
kde-quality@...
https://mail.kde.org/mailman/listinfo/kde-quality