Про стиль (coding convention) — различия между версиями
Материал из SEWiki
Linsky (обсуждение | вклад) |
Linsky (обсуждение | вклад) |
||
Строка 2: | Строка 2: | ||
Ниже приведен минимальный набор правил, которые встречаются в большинстве "договоров" (их выполнения мы будем контролировать). | Ниже приведен минимальный набор правил, которые встречаются в большинстве "договоров" (их выполнения мы будем контролировать). | ||
− | + | * В рамках одного проекта у всех файлов стиль один (у нас в рамках | |
одной лабы или дз) | одной лабы или дз) | ||
− | + | * Лучше не жалеть пробелов | |
<nowiki> | <nowiki> | ||
Строка 12: | Строка 12: | ||
</nowiki> | </nowiki> | ||
− | + | * У вложенных конструкций должны быть отступы | |
<nowiki> | <nowiki> | ||
Строка 21: | Строка 21: | ||
</nowiki> | </nowiki> | ||
− | + | * Лучше не жалеть пустых строк | |
<nowiki> | <nowiki> | ||
Строка 37: | Строка 37: | ||
</nowiki> | </nowiki> | ||
− | + | * Перед отправкой на проверку желательно убрать все временно закомментированные участки кода | |
− | + | * Имена | |
− | + | Должны быть осмысленные имена у переменных и функций. Желательно, чтобы имена функций начинались с глагола. | |
− | Желательно, чтобы имена функций начинались с глагола. | + | Несколько слов в составе идентификатора лучше разделить (getNextPacket или get_next_packet неважно, главное, чтобы везде одинаково). |
− | Несколько слов в составе идентификатора лучше разделить (getNextPacket | + | |
− | или get_next_packet неважно, главное, чтобы везде одинаково). | + | |
Минимум сокращений (cur ---> current). Счетчиков в цикле это не касается. | Минимум сокращений (cur ---> current). Счетчиков в цикле это не касается. | ||
− | Транслитерация с русского языка в именах переменных и функций не | + | Транслитерация с русского языка в именах переменных и функций не приветствуется (massive, stroka --- отказать :) |
− | приветствуется (massive, stroka --- отказать :) | + | |
− | + | * В проекте должен быть Makefile, который по умолчанию делает сборку (но не запуск!). В Makefile должна быть цель clean, удаляющие все сгенерированные файлы. | |
− | + | * А где еще почитать? | |
[https://google.github.io/styleguide/cppguide.html Style guide] (Google) | [https://google.github.io/styleguide/cppguide.html Style guide] (Google) | ||
[http://mit.spbau.ru/sewiki/images/c/ce/Cpp_Standard_mistakes_shad.pdf Cтандартные ошибки] (ШАД) | [http://mit.spbau.ru/sewiki/images/c/ce/Cpp_Standard_mistakes_shad.pdf Cтандартные ошибки] (ШАД) |
Версия 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тандартные ошибки (ШАД)