Про стиль (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тандартные ошибки (ШАД)