This is an old revision of the document! Table of ContentsRosegarden Coding StyleRosegarden house style is as follows, in approximately descending order of importance: NamesClass names are UpperCamelCase, method names are lowerCamelCase, non-public member variables are m_prefixedCamelCase, slot names start with “slot”. IndentationIndentation is by four spaces at a time. There should be no tab characters anywhere in Rosegarden source code. The indentation should look the same regardless of whether you read it in an IDE, in a terminal window with “cat” or “vi”, in Emacs, or quoted in an email. It must not depend on having the right settings for tab-to-space conversion in your IDE when you read it. (Emacs and vim users will note that we already start every source file with a meta-comment that sets up the right indentation mode in these editors.) NamespacesNo extra indentation inside namespaces; set off inner code by two carriage returns on either side of namespace brackets namespace Rosegarden { // 1 // 2 class SomeUsefulClass { //code }; // 1 // 2 } BracesBraces are what you might call Java-style, which means: int SomeClass::someMethod(int f) { int result = 0; if (f >= 0) { for (int i = 0; i < f; ++i) { result += i; } } else { result = -1; } return result; } ifSingle statement blocks are preferably either “inline” or bracketed. Like this: if (something) somethingElse(); else someOtherThing(); if (something) { somethingElse(); } else { someOtherThing(); } but not: if (something) somethingElse(); Parentheses and Whitespace
Whitespace is much as in the above examples (outside but not inside connect(detailsButton, SIGNAL(clicked(bool)), this, SLOT(slotDetails())); but not: connect( detailsButton, SIGNAL( clicked(bool) ), this, SLOT( slotDetails() ) ); and please avoid: if( something) if(something)
No whitespace between Pointers
Pointers are Argument Alignment
connect(m_pluginList, SIGNAL(activated(int)), this, SLOT(slotPluginSelected(int))); but not: connect(m_pluginList, SIGNAL(activated(int)), this, SLOT(slotPluginSelected(int)));
CommandHistory::getInstance()->addCommand(new SegmentSyncCommand( comp.getSegments(), selectedTrack, dialog.getTranspose(), dialog.getLowRange(), dialog.getHighRange(), clefIndexToClef(dialog.getClef()))); Comments
//&&& This code was deleted temporarily // for (int m = 0; m <= n; ++m) { // int x = s.x() + (int)((m * ((double)m * ax + bx)) / n); // int y = s.y() + (int)((m * ((double)m * ay + by)) / n); // } but not: //&&& This code was deleted temporarily /* for (int m = 0; m <= n; ++m) { int x = s.x() + (int)((m * ((double)m * ax + bx)) / n); int y = s.y() + (int)((m * ((double)m * ay + by)) / n); } */ (The reason C++-style comments are preferred is not arbitrary. C++-style comments are much more obvious when viewing diffs on the rosegarden-bugs list, because they force the entire block of text to be displayed, instead of only the starting and ending lines.) #include OrderIncludes should try to follow the following pattern: #include "MyHeader.h" #include "MyCousinClassHeader.h" #include "MyOtherCousin.h" #include "RosegardenHeader.h" #include "base/SomeOtherHeader.h" #include <QSomeClass> #include <QSomeOtherClass> #include <some_stl_class> #include <some_other_stl_class> SwitchSwitch statements are all over the place, and we need to pick one style and use it, so we'll call this a good switch statement: switch (hfix) { case NoteStyle::Normal: case NoteStyle::Reversed: if (params.m_stemGoesUp ^ (hfix == NoteStyle::Reversed)) { s0.setX(m_noteBodyWidth - stemThickness); } else { s0.setX(0); } break; case NoteStyle::Central: if (params.m_stemGoesUp ^ (hfix == NoteStyle::Reversed)) { s0.setX(m_noteBodyWidth / 2 + 1); } else { s0.setX(m_noteBodyWidth / 2); } break; }
and this a bad one (note particularly the switch(layoutMode) { case 0 : findAction("linear_mode")->setChecked(true); findAction("continuous_page_mode")->setChecked(false); findAction("multi_page_mode")->setChecked(false); slotLinearMode(); break; case 1 : findAction("linear_mode")->setChecked(false); findAction("continuous_page_mode")->setChecked(true); findAction("multi_page_mode")->setChecked(false); slotContinuousPageMode(); break; case 2 : findAction("linear_mode")->setChecked(false); findAction("continuous_page_mode")->setChecked(false); findAction("multi_page_mode")->setChecked(true); slotMultiPageMode(); break; } Varables
int spacing = 3; bool useHoops = false; doSomething(spacing, useHoops); avoid: doSomething(3, false); Note that you should not feel like you have to take this to ridiculous extremes. Just bear it in mind, especially when it's something obscure enough you've just had to go look at the header or the API yourself to figure out what some static parameter was for.
int i; int mi = -2; int md = getLineSpacing() * 2; int testi = -2; int testMd = 1000; for (i = -1; i <= 1; ++i) { int d = y - getSceneYForHeight(ph + i, x, y); if (d < 0) { d = -d; } if (d < md) { md = d; mi = i; } if (d < testMd) { testMd = d; testi = i; } } Menu ItemsMenu items use title case. We don't capitalize pronouns except pronouns “standing alone” (exhaustive pronouns). For instance, “Move to Staff Above”. We use trailing dots “…” to indicate that a menu item leads to a dialog. For example: <Action name="general_move_events_up_staff" text="&Move to Staff Above..." /> See also: |