koffice/chalk/HACKING

Since 1999, people have been hacking on Chalk. Everyone brought their
own coding style, their own code conventions, their own likes and
dislikes. Me, (Boudewijn that is), I like indents of four spaces, and
no scope prefixes for variables. However, in the interests of
consistency, these are the rules new code should adhere to:


Indentation

	With four spaces. Use the default Java indentation
	style of (X)Emacs or KDevelop -- also for brace placement.

Includes

	Avoid as much as possible #includes in header files; use forward declarations
	of classes.

Initializers

	Avoid as much as possible initializers in the body of the constructor. Use
	initializer lists instead.

Scope prefixes

	Use only m_ for class-level variables. No other scope prefixes; no g_, l_,
	no 'p' for pointer variables.

Shared pointers

	Use shared pointers wherever possible.

Getter/setter

	Chalk doesn't use TQt's properties -- yet. If you want to introduce use of
	properties, convert any and all classes in Chalk before committing.

	Getter/setters are named 'x() for getters and setX(int x) for setters. If you
	come across violations of this rule, change the code.	

Class naming

	If you use a well-known design pattern, name the class according to the design
	pattern. All files should start with 'kis_', all classes with the 'Kis' prefix.
	In filenames, separate words with an underscore; in classnames use capital letters. 
	Example: kis_new_class.h/KisNewClass.

	The only exception to this rule are interfaces.
	Example: kis_tool.h/KisToolInterface.

Function naming

	Functions should be named in camelBackedFashion, to conform to TQt's standards.
	If you encounter functions in c_style_like_this, feel free to rename. Also:
	verbNoun -- i.e., rotateLayer, not layer_rotate. The latter is a true c-ism,
	introduced by a language that needs to prefix the 'class' name to every function
	in order to have something that not quite OO.

Variable/Parameter names

	Variable/parameter names start with an undercast letter. A name composed of different
	words is done in camelBackedStyle.

Designer

	Chalk has started to use designer. All dialogs and all widgets that have a layout
	manager must be done in designer. We don't add code nor add signal/slot connections
	in designer

Enums

	All enums should be prefixed with 'enum'.

Namespaces

	Currently, we only use anonymous (right term?) namespaces for things like undo
	commands. For the rest, some classes have a 'Kis' prefix, others don't. This should
	be made consistent, and we might want to use namespaces to keep all of Chalk
	inside.

Files and classes

	It's preferred (and strongly preferred) to have only one class per .h/.cpp file.
	(Which is logical, because otherwise you won't be able to keep to the naming scheme.)

Spaces

	Keep the source airy and open. (However, maybe I was wrong in wanting spaces around ->...)

Slots and signals

	Prefix slots with slot and signals with sig: slotUpdateSelection, sigSelectionUpdated.

Boudewijn Rempt