summaryrefslogtreecommitdiffstats
path: root/juk/HACKING
diff options
context:
space:
mode:
authortoma <toma@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2009-11-25 17:56:58 +0000
committertoma <toma@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2009-11-25 17:56:58 +0000
commite2de64d6f1beb9e492daf5b886e19933c1fa41dd (patch)
tree9047cf9e6b5c43878d5bf82660adae77ceee097a /juk/HACKING
downloadtdemultimedia-e2de64d6f1beb9e492daf5b886e19933c1fa41dd.tar.gz
tdemultimedia-e2de64d6f1beb9e492daf5b886e19933c1fa41dd.zip
Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features.
BUG:215923 git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdemultimedia@1054174 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
Diffstat (limited to 'juk/HACKING')
-rw-r--r--juk/HACKING147
1 files changed, 147 insertions, 0 deletions
diff --git a/juk/HACKING b/juk/HACKING
new file mode 100644
index 00000000..2fb4d392
--- /dev/null
+++ b/juk/HACKING
@@ -0,0 +1,147 @@
+Since I tend to be one of the more pedantic people on coding style I'll provide
+a bit of a reference here. Please take a few minutes to read this as it will
+save us both time when processing patches.
+
+================================================================================
+Indentation
+================================================================================
+
+The older files in JuK are indented using Qt-style. The first level was 4
+spaces, the second one tab, the third one tab followed by 4 spaces. I'm not
+particularly fond of this style anymore, but it used to be the Emacs default
+when using the KDE Emacs scripts.
+
+static void foo()
+{
+ if(bar()) // <-- 4 spaces
+ baz() // <-- 1 tab
+}
+
+Newer files simply use 4 spaces at all levels. In most cases the style of the
+file currently being worked in should be followed. So:
+
+static void foo()
+{
+ if(bar()) // <-- 4 spaces
+ baz() // <-- 8 spaces
+}
+
+================================================================================
+Braces
+================================================================================
+
+Braces opening classes, structs, namespaces and functions should be on their own
+line. Braces opening conditionals should be on the same line with one notable
+exception: if the conditional is split up onto several lines then the opening
+brace should be on its own line. i.e.
+
+class Foo
+{
+ // stuff
+};
+
+if(foo == bar) {
+ // stuff
+}
+
+while(foo == bar &&
+ baz == quux &&
+ flop == pop)
+{
+ // stuff
+}
+
+static void foo()
+{
+ // stuff
+}
+
+Other exceptions include inline functions that are just returning or setting a
+value. However multiple statements should not ever be combined onto one line:
+
+class Foo
+{
+public:
+ String value() const { return m_value; }
+};
+
+Also conditionals / loops that only contiain one line in their body (but where
+the conditional statement fits onto one line) should omit braces:
+
+if(foo == bar)
+ baz();
+
+But:
+
+if(baz == quux &&
+ ralf == spot)
+{
+ bar();
+}
+
+================================================================================
+Spaces
+================================================================================
+
+Spaces should not be used between the conditional / loop type and the
+conditional statement. They should also not be used after parenthesis. However
+the should be to mark of mathematical or comparative operators.
+
+if ( foo == bar )
+ ^ ^ ^
+
+The marked spaces should be ommitted to produce:
+
+if(foo == bar)
+
+================================================================================
+Header Organization
+================================================================================
+
+Member variables should always be private and prefixed with "m_". Accessors may
+be inline in the headers. The organization of the members in a class should be
+roughly as follows:
+
+public:
+public slots:
+protected:
+protected slots:
+signals:
+private: // member funtions
+private slots:
+private: // member variables
+
+If there are no private slots there is no need for two private sections, however
+private functions and private variables should be clearly separated.
+
+The implementations files -- .cpp files -- should follow (when possible) the
+same order of function declarations as the header files.
+
+Virtual functions should always be marked as such even in derrived classes where
+it is not strictly necessary.
+
+================================================================================
+Whitespace
+================================================================================
+
+Whitespace should be used liberally. When blocks of code are logically distinct
+I tend to put a blank line between them. This is difficult to explain
+systematically but after looking a bit at the current code organization this
+ideally will be somewhat clear.
+
+Also I tend to separate comments by blank lines on both sides.
+
+================================================================================
+Pointer and Reference Operators
+================================================================================
+
+This one is pretty simple. I prefer "Foo *f" to "Foo* f" in function signatures
+and declarations. The same goes for "Foo &f" over "Foo& f".
+
+================================================================================
+
+There are likely things missing here and I'll try to add them over time as I
+notice things that are often missed. Please let me know if specific points are
+ambiguous.
+
+Scott Wheeler <wheeler@kde.org>