1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/emnetsliym-riot

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
CODING_CONVENTIONS.md 16 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
gitlife-traslator Отправлено 26.11.2024 09:43 5e774d9

Функции

  • Каждой функции нужен прототип в дополнение к её определению. Если прототип указан в файле .c, он должен быть объявлен ДО любых определений функций.
  • Если область действия функции ограничена одним файлом, она ДОЛЖНА быть объявлена как static.
  • Функции без параметров должны быть указаны с (void).
  • Делайте функции короткими! Как правило, тело функции не должно превышать один экран.
  • НЕ используйте глобальные макросы, определяющие более одной строки кода. Вместо этого используйте встроенные функции.

Возвращаемые значения

  • Любая функция должна возвращать одно из следующих значений:
    • логическое значение (ноль или не ноль);
    • код ошибки (заданный как отрицательное число или ноль) или положительное значение статуса;
    • количество прочитанных или записанных байтов/значений для функций ввода-вывода;
    • позиция или адрес (для функций поиска);
    • указатель.
  • NULL также указывает на ошибку.
  • Не возвращайте структуры или другие большие типы! Они будут скопированы в стек, что приведёт к дорогостоящим операциям. Кроме того, некоторые компиляторы имеют проблемы с большими типами возврата. Используйте указатели на структуры и позаботьтесь о времени жизни структур.
  • По возможности предпочитайте подписанные типы неподписанным, чтобы иметь возможность добавлять коды ошибок позже.

Именование

  • Имена всех публичных функций и переменных должны начинаться с имени соответствующей библиотеки, например:
thread_getpid(void);
hwtimer_init_comp(uint32_t fcpu);
int transceiver_pid;
  • Частные функции и переменные не имеют этого префикса библиотеки.
  • НЕ используйте CamelCase. Имена функций, переменных и файлов, а также перечисления, структуры или typedefs пишутся строчными буквами с подчёркиваниями.
/* вместо: */
void CamelCaseNamedFunction(int camelCaseNamedVar);

/* пишите: */
void camel_case_named_function(int camel_case_named_var);
  • При реализации констант или переменных, которые определены в сторонних документах, таких как RFC, добавьте префикс к этим именам на основе соглашений кодирования RIOT. Если вы используете имя в коде RIOT, которое отличается от имени в стороннем документе, вы должны добавить ссылку на исходное имя константы или переменной в документации Doxygen.

Отступы и фигурные скобки

  • Отступы составляют четыре пробела (то есть БЕЗ символов табуляции).
  • В отличие от стиля кодирования Linux, закрывающая фигурная скобка стоит на отдельной строке, если за ней следует else. Когда за ней следует while в операторе do, она идёт в той же строке.
  • Используйте фигурные скобки даже для однострочных блоков. Это улучшает отладку и последующие дополнения.
/* вместо: */
if (debug) println("DEBUG");
else println("DEBUG ELSE");

/* напишите: */
if (debug) {
println("DEBUG");
}
else {
println("DEBUG ELSE");
}
  • За запятыми всегда следует пробел.
  • Для сложных операторов всегда полезно использовать больше скобок — или разбить оператор и упростить его.

Включает

  • Включаемые системные заголовки (в <>-скобках) всегда предшествуют специфическим для RIOT включает (в кавычках).
  • Факультативные заголовки должны включаться только в том случае, если их соответствующий модуль выбран/собирается. Другими словами: всегда помещайте #ifdef MODULE_... вокруг включений факультативных заголовков:
#ifdef MODULE_ABC
#include "abc.h"
#endif

Защитные элементы заголовков

Все файлы должны иметь защитные элементы заголовков вида:

#ifndef PATH_TO_FILE_FILENAME_H
#define PATH_TO_FILE_FILENAME_H

...
#endif /* PATH_TO_FILE_FILENAME_H */

Правила создания имени защиты:

  1. возьмите имя файла;
  2. если в пути к файлу есть include/, включите путь оттуда;
  3. замените "/" и "." на "_";
  4. преобразуйте в прописные буквы;
  5. если полученный защитный элемент начинается с "_", добавьте префикс "PRIV".

Примеры:

  • "core/include/msg.h" -> "MSG_H";
  • "sys/include/net/gnrc/pkt.h" -> NET_GNRC_PKT_H;
  • "drivers/abcd0815/abcd0815_params.h" -> ABCD0815_PARAMS_H;
  • "sys/module/_internal.h" -> PRIV_INTERNAL_H.

Примечание: эти правила будут применяться CI.

Совместимость с C++

  • Файлы заголовков C должны быть Всегда оборачивать для совместимости с C++, чтобы предотвратить проблемы с искажением имён, то есть помечать все содержащие функции и определения как extern "C":
#ifdef __cplusplus
extern "C" {
#endif

... все ваши объявления функций, глобальные переменные и определения принадлежат здесь

#ifdef __cplusplus
}
#endif

Абсолютные значения должны быть указаны как макросы или перечисления, а не как литералы, т. е. вместо:

int timeout = 7 * 1000000;

писать:

int timeout = TIMEOUT_INTERVAL * USEC_PER_SEC;

Комментарии: все комментарии должны быть написаны в стиле комментариев C. Например:

/* Это комментарий в стиле C */

Неверно:

// Комментарий C++ здесь

Документация:

  • Вся документация должна быть на английском языке.
  • Все файлы содержат примечание об авторских правах и автора.
  • Документация Doxygen обязательна для всех заголовочных файлов.
  • Каждый заголовочный файл включает общее описание предоставляемой функциональности.
  • Каждая функция должна быть документирована, включая параметры и возвращаемое значение.

Пример документации Doxygen в заголовочном файле может выглядеть так:

/*
 * Copyright (C) 2014 Peter Schmerzl <peter@schmerzl-os.org>
 *
 * Этот файл подчиняется условиям и положениям GNU Lesser General Public License v2.1. Подробнее см. файл LICENSE в верхнем каталоге.
 */

/**
 * @ingroup foobar
 * @{
 *
 * @file
 * @brief Определения для функций foo и bar.
 *
 * Более подробная информация о файле и реализованной функциональности.
 *
 * @author Peter Schmerzl <peter@schmerzl-os.org>
 *
 */

/**
 * @brief Установить состояние foobar.
 *
 * @param[in] state Новое состояние foobar.
 * @param[out] old_state Старое состояние foobar записывается в эту переменную.
 *
 * @return 1, если установка состояния прошла успешно, 0 в противном случае.
 */
 int set_foobar(int state, int *old_state);

Общие предупреждения компиляции: некоторые решения для правильной обработки предупреждений компиляции.

-Wformat: решение для ошибок форматирования строк:

  • При печати size_t: используйте %u и приведите переменную к (unsigned), потому что newlib-nano не поддерживает %zu пример.
  • При печати unsigned char/uint8_t: используйте %u, потому что newlib-nano не поддерживает %hu/PRIu8 пример.
  • При печати uint32_t: используйте формат печати PRIu32 пример.
  • При печати 64-битных переменных: это не поддерживается newlib-nano, как сказано здесь ссылка. Рекомендуется использовать модуль fmt для этих целей. Пример.

-Wformat-nonliteral: для функции printf со следующей ошибкой: error: format string is not a string literal.

  • Функция, использующая переменное количество аргументов: используйте __attribute__((__format__ (__printf__, 3, 4))), где здесь 3 — номер аргумента с форматом, а 4 — аргументы формата, начиная с 1. См. пример.
  • Функция, использующая va_list: используйте __attribute__((__format__ (__printf__, 1, 0))), где 1 — номер аргумента с форматом и 0, поскольку нет переменного количества аргументов. См. пример.

Git: делайте один коммит на изменение. Первая строка сообщения о фиксации описывает основную функцию фиксации.

Непрерывная интеграция: если тесты CI терпят неудачу из-за... Ошибки необходимо исправить.

  • Если тесты CI завершаются неудачно из-за предупреждений или ошибок, выдаваемых cppcheck, следует попытаться исправить ошибку. Если ошибка определённо является ложным срабатыванием, существует возможность подавить это предупреждение/ошибку. Вы ДОЛЖНЫ сделать это, добавив комментарий, включая обоснование, почему это ложное срабатывание и почему код не может быть исправлен иначе, в следующем формате:
    /* cppcheck-suppress <категория ошибки/предупреждения>
     * (причина: cppcheck ведёт себя очень глупо. это точно не разыменование нулевого указателя) */

Соглашения по оформлению кода на Python

  • Код должен соответствовать версии Python 3.5 как минимум, поскольку это версия Python 3 по умолчанию в Ubuntu 16.04 (используется в качестве системы отсчёта для CI).
  • При запуске инструмента Flake8 код не должен выдавать ошибок, например:
    • для проверок стиля, описанных в PEP8,
    • для линтер-проверок, предоставляемых Pyflakes,
    • для комплексных проверок, предоставляемых проектом McCabe.
  • Допускается длина строки максимум 120 символов вместо 79 по pep8: это повышает читаемость тестов, так как они могут ожидать длинные строки вывода.
  • Только запускаемые скрипты должны начинаться с #!/usr/bin/env python3
  • Запускаемые скрипты должны использовать следующую схему:
#!/usr/bin/env python3

# Copyright (C) <your copyright>
#
# Этот файл подчиняется условиям и положениям GNU Lesser
# General Public License v2.1. Более подробную информацию см. в файле LICENSE в верхнем уровне каталога.

# поместите импорт модулей первым
# см. https://www.python.org/dev/peps/pep-0008/#imports
# для более подробной информации
import module1
import module2

# Необязательные глобальные переменные
GLOBAL_VARIABLE = "I'm global"


# локальные функции, если требуется
def local_func():
    # Поместите сюда код вашей локальной функции


# Основная функция
def main_func():
    # Поместите здесь основной код


if __name__ == "__main__":
    # Вызовите основную функцию отсюда:
    main_func()

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/emnetsliym-riot.git
git@api.gitlife.ru:oschina-mirror/emnetsliym-riot.git
oschina-mirror
emnetsliym-riot
emnetsliym-riot
master