Aslo see: PathShapes API REview
There are various rules to follow to make code as clean as possible.
- Make everything in a library class private unless there is someone explicitly using it.
- Move most code that is in header files which will be installed to the cpp file in order to stop it from being inline. The idea here is that if you install a header file for external parties can use, you should not also export the implementation since that will give really weird errors if the library used has slightly different implementation than the library linked against.
- Make use of d pointers in all exported classes.
- We use private slots quite often. Which look private, but in reality are not. On Windows this problem gets even worse where external classes can even call the slot. We should move all such slots to the d-pointer class and use the Q_PRIVATE_SLOT Qt macro. See: kde-core-devel mail
- remove all 'virtual' keywords on base classes while the method has not been extended anyway.
- Rename enums that have the name 'Enum' in it.
- Make sure enums are properly CamelCased
- rename methods (as well as signals and slots) to no longer have the 'sig' / 'slot' prefix in them.
- Use d-pointers everywhere (in exported classes)
- move private methods and slots out of exported headers.
- rename all methods / classes to no longer have an abbreviation.
- avoid boolean options in methods. Create a simple enum instead.
November meeting conclusions
- for every library, write a toplevel apidox file that explains the rationale, the purpose and the raison d'etre of that library.
- strive to minimize includes in header
- strive to minimize and hide dependencies
- kostore: remove the kio dependency (which is only used to access tar balls) and copy the currently private zip reading/writing code from Qt: this will be removed when that code moves to qtcore after api review. Combine KoStore and KoOdf into one library.
check whether qlocale can replace klocale in KoUnit. If so, move KoBase into KoOdf.
Split KoResources. Move the gradient and other resource clases into pigment, and move the resource server etc. classes to kowidgets. (boud)
Move koaction into komain. (boud)
use KPluginLoader instead KoPluginloader from KoPlugin. (boud) Not feasible.
Move kogenericregistrymodel into the kowidget library (boud)
Move the KoGenericRegistry template class to koffice/interfaces (boud)
- undepend kowidgets and kotext
split lcms from pigment into a separate plugin (boud)
- rename komain to komvc? (We discussed this, but I'm not sure we came to a decision)
This page was last modified on 6 December 2010, at 17:59. Content is available under Creative Commons License SA 4.0
unless otherwise noted.