Developers and getting them to improve their code.

[Benjamin Meyer]

Well I currently work for Sharp on the Zaurus project and for the last ye=
ar I=20
have been in a unique position of looking at optimization and how it appl=
ies=20
to Qt/KDE/C++.

Some basic things that may or may not have already been discussed.  Pleas=
e=20
point out any errors/corrections in the following.

These actions are much more developer oriented to get them to adapt the=20
program to be faster/better/smaller.  Improving GCC is one outside way an=
d=20
cleaning up applications is another.

A C++ optimization guide.  I have searched online and found many little o=
ne=20
liner hints.  Some are obvious, but others aren't.  I really haven't foun=
d a=20
common book/faq/website that has C++ optimizations.  This should really g=
et=20
top priority for there are many C++ tricks that even old C++ developers d=
on't=20
know about and most new C++ developers have never even thought about. =20
Putting together a comprehensive listing and asking for feedback from the=
=20
community is a good project that would pay for itself many times over.

Along the same lines a tutorial for how to use valengrind would be good.

One of the things I have found is that many developers simply are not awa=
re of=20
a pre-existing class that already exists and implement  (poorly) themselv=
es. =20
Sometimes it is even such a simply thing as linked lists.  The best case =
of=20
this is KConfig/QSetting/Config etc, the developer often re-implements th=
is=20
and later pulls it out.  Maybe creating some sort of program where develo=
pers=20
can ask for peer review of the design of there application.

Code bloat. Between Qt and KDE there are a number of classes that do the =
same=20
thing such as far as the developer is concerned.  (Such as QSocket/KSocke=
t). =20
These classes confuse developers for they don't know what to write for.  =
Even=20
having them have the same api (minus class name) is a good start.  Combin=
ing=20
these classes [with the help of TrollTech] would not only reduce binary s=
ize=20
of the libraries it would free up developers who are doing duplication of=
=20
work of enhancing these classes.

I forget where I saw it, but there is a compiler that when compiling will=
 spit=20
out messages about code that is unessesary in release versions because th=
ey=20
will bloat the binary's quite a bit.  ( Such as the assert() call ) so th=
at=20
developers can check to see if those calls are really needed and=20
remove/change them.

uic last I checked (this may be wrong in 3.1) will generate extra code wh=
ere=20
it is not needed.  Making uic be a little smarter about how it generates =
its=20
files wont improve much on the application scall, but overall it will do =
a=20
bit of good.

Comment?  Additions?

Suffice it to say this really comes down to creating a developer site (ju=
st a=20
few pages) with many tips and tricks on how to improve the applications s=
peed=20
and size.

-Benjamin Meyer