Hello, habrazhiteli!

Now, a specialist with many years of experience working with Qt thought: “What the hell? Habr - for things more abruptly! ". But even specialists with many years of experience sometimes need to read such articles about simple things, because this is important. Code is one of the most important components of programming. And our task is to keep it clean. This article is dedicated to all Qt programmers who strive for the ideal.

Of course there is an article on the Qt Project - Qt Coding Style . Only here there is less valuable material ...

')

Postulate number 1. Alignment

In Qt, it is common to use indents of 4 spaces each. But precisely 4, and precisely space. Using \ t or other width spaces is terribly bad and is severely punished .

Postulate number 2. Variable declaration

One of the most important postulates, as it defines readability and the overall style of the code. The rules for declaring variables are compiled into this list:

• Declare each variable on a separate line.
• Avoid short or concise names (for example, "a", "rbarr", "nughdeget")
• Wait until the variable is needed, and only then declare it.
• Functions and variables must be in camelCase
• Avoid abbreviations and all acronyms.
• Classes must always begin with a capital letter.
• Public classes must begin with the letter 'Q' (QRgb), then the capital letter
• Public functions must begin with the letter 'q' (qRgb)
• Abbreviations must be in PascalCase (for example, QXmlStreamReader instead of QXMLStreamReader)

//  int a, b; char *c, *d; //  int height; int width; char *nameOfThis; char *nameOfThat; 

 //  short Cntr; char ITEM_DELIM = '\t'; //  short counter; char itemDelimiter = '\t'; 

Postulate number 3. Spaces

Spaces are a very important element of source code formatting. It plays a very large role in the readability of the code.

• Use spaces to group individual code segments.
• Only one blank line can be used for separation.
• Always use only one and only one space after the keyword and curly brace
• For pointers and references, always use a single space between the type and '*' or '&', but never put a space between the '*' or '&' and the variable name
• Surround binary operators with spaces.
• No spaces after casting
• Try to avoid C-like ghosts.

 //  if (foo){ } //  if (foo) { } 

 char *x; const QString &myString; const char * const y = "hello"; MyClass *obj = new MyClass(this); bool ok; obj.report(1, &ok); 

 //  char* blockOfMemory = (char* ) malloc(data.size()); QTextStrem newOne(..); newOne<<"Hello"<<","<<" "<<"world"; //  char *blockOfMemory = reinterpret_cast<char *>(malloc(data.size())); QTextStrem newOne(..); newOne<< "Hello" << "," << " " << "world"; 

Postulate number 4. Parentheses

Brackets are generally a separate topic. They, like the spaces, play the lion's share in the appearance and readability of the code

• As a basic rule, the left brace is on the same line as the operator:
• Exception : The implementation of functions and class declarations always, absolutely always have a left bracket on a new line:
• Use curly brackets when the body of the condition contains more than one line, and if a single-line operator is something complex
• Exception 1 : Also use parentheses if the parent operator occupies several lines or wrappers.
• Exception 2 : Also use brackets in if-else blocks where the if-code or else-code takes several lines
• Use curly brackets when the body of the operator is empty

 static void foo(int g) { qDebug("foo: %i", g); } class Moo { public: Moo(); Moo(int a, int b); public slots: int getResult(); protected slots: void processNumbers(); private: int mineA; int mineB; int mineResult; }; 

 //  if (address.isEmpty()) { return false; } for (int i = 0; i < 10; ++i) { qDebug("%i", i); } //  if (address.isEmpty()) return false; for (int i = 0; i < 10; ++i) qDebug("%i", i); 

 //  while (a); if (expression) else // do something //  while (a) {} if (expression) { } else { // do something } 

 //  if (codec) { // do something } //  if (codec) { // do something } 

 //  if (address.isEmpty()) return false; else { qDebug("%s", qPrintable(address)); ++it; } //  if (address.isEmpty()) { return false; } else { qDebug("%s", qPrintable(address)); ++it; } //  if (a) if (b) ... else ... //  if (a) { if (b) ... else ... } 

 //  if (address.isEmpty() || !isValid() || !codec) return false; //  if (address.isEmpty() || !isValid() || !codec) { return false; } 

Postulate number 5. Round brackets

Use parentheses to group expressions:

 //  if (a && b || c) if (a + b & c) //  if ((a && b) || c) if ((a + b) & c) 

Postulate number 6. Switch Multiple Conditions

Of course, these conditions are the cause of many discussions on the part of the developers and creators of the Coding Guidelines - there may be a lot of different options. However, Qt offers exactly this option:

• Case statements must be in the same column as the switch statement.
• Each case must end with a break (or return) statement or comment to show that another case follows.

 switch (myEnum) { case Value1: doSomething(); break; case Value2: case Value3: doSomethingElse(); // fall through default: defaultHandling(); break; } 

Postulate number 7. Line break

Often the following happens: there is a developer Vasya with a large monitor. He writes his code calmly. Then this code is opened by the developer Petya, with a laptop, and he begins to see clearly - he has to scroll a lot to read the entire code. This is one of the defects in readability. What does Qt offer for salvation?

• Make sure the lines are no longer than 100 characters; cut them off if necessary
• Commas are located at the end of a broken line; Operators should be moved at the beginning of a new line. The operator at the end of the line is very easy not to see if your editor is too narrow.

 //  if (longExpression + otherLongExpression + otherOtherLongExpression) { } QMessageBox::information(d->someObjectWithLongName, tr("A long title for mesage"), tr("A very very very very very very long body", QMessageBox::Ok, QMessageBox::Cancel); //  if (longExpression + otherLongExpression + otherOtherLongExpression) { } QMessageBox::information(d->someObjectWithLongName, tr("A long title for mesage"), tr("A very very very very very very long body", QMessageBox::Ok, QMessageBox::Cancel); 

UPD: the last part of the code is displayed incorrectly - all the lines should be on the same level

Postulate number 8. Inheritance and the `virtual` keyword

In this postulate, everything is extremely simple - the main thing is not to write `virtual` before the name of the method to be redefined in the .h file.

 //  class MyWidget : public QWidget { ... protected: virtual void keyPressEvent(QKeyEvent *); //  class MyWidget : public QWidget { ... protected: void keyPressEvent(QKeyEvent *); 

Postulate number 9. General exception

This postulate tells us that there is nothing wrong if you break a rule, but only if it makes your code ugly. This is a good example of the fact that all rules have exceptions, and that rules are created to violate them.

Unfortunately, I could not find an example when the Qt Coding Guidelines make the code ugly.

Completion

I am afraid that this is the end of my article about the style of writing code in Qt. Let me remind you once again that only it is quoted for controlling in Qt, so if you are going to contribute to the development of the project, you will have to use these postulates anyway, but do not forget - you can break the rules :).

For me, Qt Coding Style is just the perfect style for writing code. I find it clean, comfortable, pleasant. For all the time of its use I have not had any problems with the readability of the code. Would I recommend it? Of course yes! Moreover, I think that it is him who should be promoted to all newbies on the Qt platform.

Thanks for attention.