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:
В классах public полей следует избегать, предпочитая для доступа к полям методы.
Ну я в принципе использую геттры/сеттеры.
Byte:
Комментарии предпочтительно писать на английском, да и в целом - русский текст только в файлах локализаций.
Вот с этим туго. Комментов пока 0. А по поводу коммитов что думаешь? Nex возмущается, когда я на английском комменты делаю :)
Byte:
Из этих двух вариантов я за вариант 2, так как указание “ссылка”/”указатель” является скорее частью типа переменной, чем частью имени
А если астериск/амперсанд перед именем переменной, то, на мой взгляд, нагляднее, что это переменная - указатель/ссылка. Хотя, с другой стороны, в объявлении функции используется “тип пробел */&”… гм.. запутался :(
Для префиксов можно использовать либо “m_”, либо подчеркивание:
int m_count; // так
int _count; // или так
Разумеется, использовать нужно будет что-то одно.
Мне всё равно, выберите любое.
Комментарии предпочтительно писать на английском, да и в целом - русский текст только в файлах локализаций.
Я категорически против. Комментарии на английском труднее читать и труднее писать, это усложняет всё. Я понимаю что это пожелание чтобы проект был более “интернациональным”, но давай смотреть правде в глаза: у нас нет ни разработчиков платформы, ни авторов, не знающих русский язык. И от комментариев на английском они сами собой не появятся. Могут появиться только если эту интернациональную сторону QSP активно продвигать, но этим сейчас никто не занимается и в ближайшем будущем не предвидится. Просто нет никого, кому это было бы реально нужно. Поэтому пока таковые разработчики платформы и авторы игр не появятся, интернациональности вполне хватит в виде языковых файлов. Незачем плодить неудобства на пустом месте ради каких-то воображаемых выгод. Если кто-нибудь займётся продижением интернациональной стороны QSP, перевести комментарии на английский будет элементарно. До тех пор, это ни к чему совершенно.
В целом. Правила должны быть направлены на повышение удобства разработки, а не на создание “идеального кода”. “Идеальный код” нам не нужен, нам нужен работающий инструмент, и чем быстрее тем лучше. Редактор, годами простаивающий в бета-версии - нет, спасибо, наелись. Чем проще, понятнее и удобнее правила, тем быстрее будет делаться редактор. Это главный ориентир.
Nex, мое мнение - документация QT на английском (да и не только она), так что разработчик априори будет знать английский.
rrock.ru,
я прекрасно знаю английский. Но это не значит что я хочу на нём писать!
Тогда есть вариант, что комментарии пишет кто как хочет :) Единственное, что очень рекомендую использовать однострочные комментарии везде, где можно.
// Вот такие
Комментарии вида /* comment */ использовать удобно во время отладки кода.