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 Qt'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 Qt'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 Q_SIGNALS Prefix Q_SLOTS with slot and Q_SIGNALS with sig: slotUpdateSelection, sigSelectionUpdated. Boudewijn Rempt