Future of teamwork plugin

[Kris Wong]

Having worked on a development team professionally for about 5 years now,
I figure I should probably throw my 2 cents in here.  There is an acceptable
balance between clean/efficient code using advanced c++ and maintainable
code.  I have been in a similar position as David before (developers complain
that it takes them to long to figure out what a particular block of code is
doing).  Simply put, the code needs to be maintainable by other developers.
This is true whether or not David is always available to maintain the plugin.
I must admit, I've never looked at the code in this plugin, but I have seen
the CC code in kdev 3.4 many times, and it is quite a bitch to try to follow.
The main problem in this code is all of the implicit casts.  It's nearly
impossible to try to follow code when different types "automagically" convert
themselves to other types.  Very rarely does this practice make sense (some 
examples might be a string class conversion to const char*, iterators, an
operator bool on a result class).

Often times I am amazed at the code David is capable of writing, but this
does not make it practical.  I am not really concerned with where this
plugin ends up living, but the concerns of other developers on the team
do make sense.  Any code that is released as part of KDevelop needs to:

1. be maintainable
2. be documented
3. follow the policies and standards of the team

I would also recommend that we discourage the use of implicit casting except
in situations were it really makes sense.  Hopefully we can avoid the need
for these discussions going forward.

My 2 cents,
Kris Wong
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3630 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070704/cb45b24b/attachment.bin>