Diff of /HACKING [000000] .. [35a63b]  Maximize  Restore

Switch to side-by-side view

--- a
+++ b/HACKING
@@ -0,0 +1,111 @@
+
+This is the coding guideline for Kdenlive.
+
+Committing
+    Auto-indent
+        Please don't use for existing files. It is very likely to break manual tweaks like:
+            const int componentFlags =   (ui->cbY->isChecked() ? 1 : 0) * HistogramGenerator::ComponentY
+                                       | (ui->cbS->isChecked() ? 1 : 0) * HistogramGenerator::ComponentSum
+                                       | (ui->cbR->isChecked() ? 1 : 0) * HistogramGenerator::ComponentR
+                                       | (ui->cbG->isChecked() ? 1 : 0) * HistogramGenerator::ComponentG
+                                       | (ui->cbB->isChecked() ? 1 : 0) * HistogramGenerator::ComponentB;
+        which are intended to improve readability.
+
+    Changelog
+        When adding a new feature, add it to the CHANGELOG file. Features often are not mentioned
+        in the bug tracker; adding it to the changelog helps keeping track of them.
+
+    Bug fixes
+        Bugs often are in mantis. When fixing a bug, add a link to the bug tracker entry in the commit log
+        and close the bug there.
+        If the bug is not in mantis, it should be (a) added (and marked as fixed) if it is an important bug,
+        or (b) not added otherwise.
+
+
+Source code comments
+    Classes
+        Each class should be shortly described in its header file.
+
+    Functions
+        Public functions should be documented as well in the header file. Especially regarding side effects!
+        (What does a programmer neeed to know in order to use this function without reading the whole source code?)
+
+    Inline comments
+        are very helpful for commands (function calls, calculations) that are not obvious. For example, what
+        does this function call do?
+
+            davinci.drawLine(0, y, scopeRect().size().width()-RGBParadeGenerator::distRight, y);
+
+        A short comment makes it obvious (also helps locating bugs when something needs to be fixed):
+
+            // Draw a horizontal line through the current mouse position
+            davinci.drawLine(0, y, scopeRect().size().width()-RGBParadeGenerator::distRight, y);
+
+
+API documentation
+    The docs can be generated by using doxygen (doxygen DoxyConfig in the main directory).
+    See [1] for an overview of doxygen commands.
+    Often used: \brief, \param, \return
+
+
+Coding style
+    This part is based on Krita's HACKING file[2].
+
+    Indentation, Braces etc.
+        4 Spaces for indentation. Always braces.
+        This is, according to the Qt4 coding style, which is documented here:
+        http://techbase.kde.org/Policies/Kdelibs_Coding_Style
+
+    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
+        Getter/setters are named x() for getters and setX(int x) for setters. If you
+        come across violations of this rule, change the code.
+
+    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.
+
+    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. In particular, there should be empty lines between function
+        declarations and definitions.
+
+    Slots and signals
+        Prefix slots with slot and signals with signal: slotUpdateSelection, signalSelectionUpdated.
+
+    Boolean operators
+        Use the standard !, !=, ==, && etc style, not the "not", "and" etc. style. Keep kdenlive code
+        using one, easily recognizable, C++ style.
+
+
+    Exceptions
+        These rules are merely guidelines for making the code consistent and more readable. In some cases
+        it makes sense to not follow some of the points mentioned above.
+
+
+[1] http://www.stack.nl/~dimitri/doxygen/commands.html
+[2] http://quickgit.kde.org/?p=calligra.git&a=blob_plain&h=3e8fcab9dd3588c0228498af2795d3b714b73d42&f=krita/HACKING

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks