QGen 5 - стандарты кодирования
Для совместной разработки важно установить стандарты кодирования.
Обсуждать будем в этой теме. Здесь же будет текущая версия стандартов.
В качестве отправной точки был взят http://qt-project.org/wiki/Qt_Coding_Style (на русский перевод не смотреть, там неадекват)
Нынешняя версия стандартов:
1. Выравнивание.
1.1 Выравнивание должно быть в 4 пробела.
1.2 Не использовать табуляцию, использовать пробелы.
2. Пробелы.
2.1 В конце строки не должно быть пробелов. Соответственно пустые строки не должны содержать пробелы.
2.2 Указатели и ссылки отделяем от типа одним пробелом и не отделяем от имени переменной.
// Правильно
char *x;
const QString &myString;
// Неправильно
char* y;
const QString& yourString;
char * z;
const QString & theirString;
2.3 Операторы *, /, +, -, %, =, ||, &&, ==, !=, |, & выделяются пробелами.
// Правильно
d = (a * b) + c;
if (doLocationExists && !exit)
// Неправильно
d = (a*b) + c;
if (doLocationExists&&!exit)
2.4 После открывающей круглой скобки и перед закрывающей круглой скобкой пробел не ставится.
// Правильно
d = (a * b) + c;
if (doLocationExists && !exit)
// Неправильно
d = ( a * b ) + c;
if ( doLocationExists && !exit )
2.5 После каста пробел не ставится.
// Правильно
d = (int)c;
// Неправильно
d = (int) c;
3. Именование.
3.1 Имена переменных и методов пишутся в такомРегистре.
3.2 Имена классов пишутся в ТакомРегистре. Если класс производный от QObject,
то в начало имени добавляется “Q”: QMyNewDialog.
3.3 Аббревиатуры пишутся так: myQspSyntaxRules.
4. В релизе не должно быть непереведённых строк.
По-моему половина этих правил - неадекват. Недавняя статья на Хабре и то лучший стиль предлагала.
Byte,
какая половина? Первый или второй пункт?
Я, например, не сторонник египетских скобок. + я отошел от визуального проектирования со времен Delphi. Для лучшего восприятия я всегда добавляю скобки в условие, потому что почти всегда приходится в условие что-либо добавлять. if ((a && b) || c) - мне такого и в 1С хватает, я это не люблю. И делю я выражение на несколько строк только тогда, когда оно выходит за пределы одного экрана.
rrock.ru,
Я, например, не сторонник египетских скобок.
ну к египетским скобкам я тоже не привычен, можно этот пункт отбросить. Всё обсуждаемо.
- я отошел от визуального проектирования со времен Delphi
Ок, можно пока что без него. Конечно, постоянная перекомпиляция чтобы увидеть изменения в форме - то ещё удовольствие, но раз такое большое желание есть, обойдёмся.
Для лучшего восприятия я всегда добавляю скобки в условие, потому что почти всегда приходится в условие что-либо добавлять. if ((a && b) || c) - мне такого и в 1С хватает, я это не люблю.
Вот тут не понял. Ты согласен на это условие или нет?
делю я выражение на несколько строк только тогда, когда оно выходит за пределы одного экрана
Ну так в стандарте о том же написано. Просто “ширина экрана” у всех разная, поэтому условились что будет 100 символов. Кстати я считаю что 120 будет в самый раз.
Расписал правила. Часть взял из Qt, часть от себя.
Предлагаю за основу взять всё же статью с Хабра: http://habrahabr.ru/post/172091/ (там более или менее адекватные правила на мой взгляд).
И договориться об оговорках. Например, я предпочитаю отделять символы ссылок и указателей с 2х сторон пробелами:
char * ptr;
const PString & str;
int *** array;
Это касается всех объявлений, в т.ч. для параметров функций/методов.
Кроме этого, суффиксы/префиксы для членов класса я предпочитаю использовать в т.ч. для protected полей, а не только для private.
Там еще есть спорные моменты, я попозже напишу.
Byte,
давай короткую версию своих правил, с уже внесёнными твоими оговорками. 90 пунктов это многовато для старта. И напиши про отличия с моей версией.
Byte,
rrock.ru,
напишите по каким пунктам из черновой версии (в заглавном посте) у вас нет возражений. Надеюсь хотя бы пункт 1 всех устраивает? Иначе заболтаем всё.
В принципе я со всем согласен, только про фигурные скобки добавь…
Согласен с пунктами: 1.1; 1.2; 2.1; 2.3; 2.4; 2.5; 3.1; 3.2; 3.3; 4
+ учитывая мои комментарии выше.
Все пункты по которым нет разногласий, выделил жирным.
Всё, что выделено жирным, считается действующим правилом.
Убрал пункт 3.4, с которым не согласен Байт:
3.4 Подчёркивания не используются.
Пока не ясно как и для чего хочет использовать подчёркивания Байт, видимо для констант. Этот пункт отложим пока не прояснится.
Также остался под вопросом пункт 2.2:
2.2 Указатели и ссылки отделяем от типа одним пробелом и не отделяем от имени переменной.
Байт предпочитает ставить пробелы с обеих сторон, у меня нет предпочтений т.к. никогда не следовал никаким стандартам. Ждём что скажет rrock.ru. Если rrock.ru согласен, принимаем поправку Байта и утверждаем пункт.
Приятно, что мы так быстро договорились по основным моментам, спасибо за отзывчивость и серьёзное отношение. Я очень ценю это.
Nex:
3.1 Имена переменных и методов пишутся в такомРегистре.
3.4 Подчёркивания не используются.
Подчеркивания обычно используются при именовании переменных класса. _так или m_так
Я с этим пока не могу определиться.
Nex:
3.3 Аббревиатуры пишутся так: myQspSyntaxRules
В смысле аббревиатуры?
Nex:
2.2 Указатели и ссылки отделяем от типа одним пробелом и не отделяем от имени переменной.
Я согласен с этим правилом. Не с “Тип * переменная”.
Подчеркивания обычно используются при именовании переменных класса. _так или m_так
Я с этим пока не могу определиться.
Ну тогда пока что пиши как придётся, а потом Байт скажет как ему надо :)
В смысле аббревиатуры?
В прямом. QSP - это аббревиатура. В имени переменной она должна начинаться с большой буквы и продолжаться маленькими. Вот так: myQspSyntaxRules. Чтобы не пришлось писать так: myQSPSyntaxRules.
Я согласен с этим правилом. Не с “Тип * переменная”.
Ну значит твоё мнение против мнения Байта. Что до меня, я склоняюсь к твоему варианту, т.к. ты основной комиттер. Слово Байту.
Кстати, еще хотелось бы уточнить, если действие в условии одно, то заключаем ли его в скобки?
// Wrong
if (address.isEmpty()) {
return false;
}
for (int i = 0; i < 10; ++i) {
qDebug("%i", i);
}
// Correct
if (address.isEmpty())
return false;
for (int i = 0; i < 10; ++i)
qDebug("%i", i);
Повторю:
Предлагаю за основу взять всё же статью с Хабра: http://habrahabr.ru/post/172091/ (там более или менее адекватные правила на мой взгляд).
И договориться об оговорках. Например, я предпочитаю отделять символы ссылок и указателей с 2х сторон пробелами:
char * ptr;
const PString & str;
int *** array;
Это касается всех объявлений, в т.ч. для параметров функций/методов.Кроме этого, суффиксы/префиксы для членов класса я предпочитаю использовать в т.ч. для protected полей, а не только для private.
Для префиксов можно использовать либо “m_”, либо подчеркивание:
int m_count; // так
int _count; // или так
Разумеется, использовать нужно будет что-то одно.
Такие префиксы используются только для private и protected полей. Для public полей (они могут быть использованы, к примеру, в структурах) префиксы использовать не следует.
В классах public полей следует избегать, предпочитая для доступа к полям методы.
Комментарии предпочтительно писать на английском, да и в целом - русский текст только в файлах локализаций.
Про “*” и “&” есть аргументы:
кто-то предпочитает указывать их сразу перед именем переменной, кто-то сразу после типа:
Вариант 1: int **array; // часто используется именно такая запись, однако для ссылок - часто используется вариант 2
Вариант 2: int** array;
И у того, и у другого варианта есть свои сторонники.
Из этих двух вариантов я за вариант 2, так как указание “ссылка”/”указатель” является скорее частью типа переменной, чем частью имени.
Однако, такая запись для многих непривычна.
Самым разумным вариантом является вариант 3:
int ** array;
Здесь лучше (из всех вариантов) видно признак указателя, и это (наглядность) важный момент.
К тому же, такая запись ясно указывает на особенный статус указателей и ссылок.
Если при указании типа нужно комбинировать ссылки / указатели, то между группами символов ставится пробел. Например:
int ** & array; // ссылка на указатель на указатель