Про стиль (coding convention) — различия между версиями
Материал из SEWiki
Linsky (обсуждение | вклад) |
Linsky (обсуждение | вклад) |
||
Строка 2: | Строка 2: | ||
Ниже приведен минимальный набор правил, которые встречаются в большинстве "договоров" (их выполнения мы будем контролировать). | Ниже приведен минимальный набор правил, которые встречаются в большинстве "договоров" (их выполнения мы будем контролировать). | ||
− | * В рамках одного проекта у всех файлов стиль один (у нас в рамках | + | * В рамках одного проекта у всех файлов стиль один (у нас в рамках одной лабы или дз) |
− | одной лабы или дз) | + | |
* Лучше не жалеть пробелов | * Лучше не жалеть пробелов |
Версия 18:14, 9 сентября 2016
Абсолютно правильного одного стиля нет. Люди обычно в начале проекта просто о чем-то договариваются. Ниже приведен минимальный набор правил, которые встречаются в большинстве "договоров" (их выполнения мы будем контролировать).
- В рамках одного проекта у всех файлов стиль один (у нас в рамках одной лабы или дз)
- Лучше не жалеть пробелов
int a = b + c; f(4, 5, "fdfdffdf');
- У вложенных конструкций должны быть отступы
for(...) { if(...) { } }
- Лучше не жалеть пустых строк
void f() { for( ...) { } if(...) { } } void g() { int b = 5 + 6; }
- Перед отправкой на проверку желательно убрать все временно закомментированные участки кода
- Имена
Должны быть осмысленные имена у переменных и функций. Желательно, чтобы имена функций начинались с глагола. Несколько слов в составе идентификатора лучше разделить (getNextPacket или get_next_packet неважно, главное, чтобы везде одинаково). Минимум сокращений (cur ---> current). Счетчиков в цикле это не касается. Транслитерация с русского языка в именах переменных и функций не приветствуется (massive, stroka --- отказать :)
- В проекте должен быть Makefile, который по умолчанию делает сборку (но не запуск!). В Makefile должна быть цель clean, удаляющие все сгенерированные файлы.
- А где еще почитать?
Style guide (Google)
Cтандартные ошибки (ШАД)