Про стиль (coding convention) — различия между версиями
Материал из SEWiki
Linsky (обсуждение | вклад) |
Linsky (обсуждение | вклад) |
||
(не показаны 3 промежуточные версии этого же участника) | |||
Строка 2: | Строка 2: | ||
Ниже приведен минимальный набор правил, которые встречаются в большинстве "договоров" (их выполнения мы будем контролировать). | Ниже приведен минимальный набор правил, которые встречаются в большинстве "договоров" (их выполнения мы будем контролировать). | ||
− | * В рамках одного проекта у всех файлов стиль один (у нас в рамках | + | * В рамках одного проекта у всех файлов стиль один (у нас в рамках одной лабы или дз) |
− | одной лабы или дз) | + | |
* Лучше не жалеть пробелов | * Лучше не жалеть пробелов | ||
Строка 40: | Строка 39: | ||
* Имена | * Имена | ||
− | + | ** Должны быть осмысленные имена у переменных и функций. | |
− | Должны быть осмысленные имена у переменных и функций. Желательно, чтобы имена функций начинались с глагола. | + | ** Желательно, чтобы имена функций начинались с глагола. |
− | Несколько слов в составе идентификатора лучше разделить (getNextPacket или get_next_packet неважно, главное, чтобы везде одинаково). | + | ** Несколько слов в составе идентификатора лучше разделить (getNextPacket или get_next_packet неважно, главное, чтобы везде одинаково). |
− | Минимум сокращений (cur ---> current). Счетчиков в цикле это не касается. | + | ** Минимум сокращений (cur ---> current). Счетчиков в цикле это не касается. |
− | Транслитерация с русского языка в именах переменных и функций не приветствуется (massive, stroka --- отказать :) | + | ** Транслитерация с русского языка в именах переменных и функций не приветствуется (massive, stroka --- отказать :) |
* В проекте должен быть Makefile, который по умолчанию делает сборку (но не запуск!). В Makefile должна быть цель clean, удаляющие все сгенерированные файлы. | * В проекте должен быть 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:16, 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тандартные ошибки (ШАД)