Difference between revisions of "Coding Guidelines"
(→Naming: - add section for #define guard naming)
|Line 46:||Line 46:|
= Structure =
= Structure =
Revision as of 22:23, 8 June 2013
Here you can find some guidelines you can orient to when writing code for Mumble. Be aware that when browsing existing Mumble code it is likely you will be able to find code not adhering to the rules written down here. In such cases feel free to submit a patch.
Please note that this page is a work in progress and as such incomplete or possibly even partly wrong. If we bring something up during review not listed here please add it.
- Newlines: Unix style (
- Encoding: UTF-8 without BOM
- Indentation: Tab
Class names should be CamelCase and descriptive of the object. Example:
class OpenURLEvent : public QEvent
Naming member variables
Class member variables use loose Systems Hungarian prefixing and are mixedCase. Example:
QString qsDesiredChannel; bool bSuppressAskOnQuit;
Naming member functions
Class member function names should be mixedCase. An exception to this rule can be Qt slots (see below). Example:
void msgBox(QString msg); void setOnTop(bool top);
Slots generally are named just like member functions. If you like you can prefix them with an "on" to indicate that they are slots. However Mumble uses the Qt signal&slot auto-connection feature extensively, so when handling signals from members functions will be named on_member_signal (prefix "on", underscore, member name, underscore, signal name). Example:
void onRecorderError(int err, QString strerr); void on_qpbStart_clicked();
Naming function parameters
Function parameter names are mixedCase and, in contrast to member variables, are not prefixed.
bool setVolumeForSessionControl2(IAudioSessionControl2 *control2, const DWORD mumblePID, QSet<QUuid> &seen);
Local names are mixedCase and, in contrast to member variables, are not prefixed.
Naming #define guards
#define guards are named in the form
to make them unique to the file.
.gitignore file in the main repositories folder. All ignores go in there, with path-restrictions where useful/possible. (For easier maintainability. Just one place to check for.)
Tipp: (If you need to add some local ignores specific to you or your environment, which you do not want to add and/or commit, add them to your