Эти стандарты кодирования GNU являются набор правил и руководящих принципов для написания программ , которые последовательно работать в рамках GNU системы. Стандарты кодирования GNU были написаны Ричардом Столлманом и другими добровольцами проекта GNU. Документ стандартов является частью проекта GNU и доступен на веб-сайте GNU. Хотя он ориентирован на написание бесплатного программного обеспечения для GNU на языке C , большая часть его может применяться в более общем плане. В частности, проект GNU поощряет своих участников всегда стараться следовать стандартам - независимо от того, реализованы ли их программы на C.
Форматирование кода
Стандарты кодирования GNU точно определяют, как форматировать большинство конструкций языка программирования C. Вот характерный пример:
int main ( int argc , char * argv []) { struct gizmo foo ; fetch_gizmo ( & foo , argv [ 1 ]); проверить : если ( Foo . тип == MOOMIN ) ставит ( "Это Мое" ); еще если ( Foo . бар < GIZMO_SNUFKIN_THRESHOLD / 2 || ( зЬгстр ( Foo . class_name , "Сниффа" ) == 0 ) && Foo . бар < GIZMO_SNUFKIN_THRESHOLD ) ставит ( "Это Сниффа." ); еще { чар * барни ; / * Указатель на первый символ после последней косой черты в имени файла. * / int wilma ; / * Приблизительный размер Вселенной. * / int fred ; / * Максимальное значение поля `bar '. * / сделать { frobnicate ( & foo , GIZMO_SNUFKIN_THRESHOLD , & barney , & wilma , & fred ); вертеться ( & foo , barney , wilma + fred ); } while ( foo . bar > = GIZMO_SNUFKIN_THRESHOLD ); store_size ( Wilma ); перейти к проверке ; } возврат 0 ; }
Последовательная обработка блоков как операторов (для целей отступов) - очень отличительная черта стиля форматирования кода GNU C; как обязательный пробел перед круглыми скобками. Весь код, отформатированный в стиле GNU, имеет свойство, заключающееся в том, что каждая закрывающая фигурная скобка, квадратная скобка или скобка отображается справа от соответствующего открывающего ограничителя или в том же столбце.
В качестве общего принципа можно рассматривать GNU Emacs [ кем? ] надежный авторитет в области стиля форматирования кода GNU. Таким образом, это желательно [ по мнению кого? ], что любой фрагмент кода, который выглядит некрасиво при отступе Emacs, изменяется в более дружественную для Emacs форму - например, путем вставки дополнительных круглых скобок.
Разделение длинных строк
«Когда вы разбиваете выражение на несколько строк, разбивайте его перед оператором, а не после него». [1]
Например:
если ( foo_this_is_long && bar > win ( x , y , z ) && сохранившееся_условие )
Комментарии
В стандартах особо подчеркивается важность комментариев на английском языке :
Пожалуйста, пишите комментарии в программе GNU на английском языке, потому что английский - это тот язык, который могут читать почти все программисты во всех странах. Если вы плохо пишете по-английски, напишите, пожалуйста, комментарии на английском как можно лучше, а затем попросите других помочь их переписать. Если вы не можете писать комментарии на английском языке, найдите кого-нибудь, кто будет работать с вами и переведет ваши комментарии на английский.
Комментарии должны состоять из полных предложений с заглавной буквы, за каждым из которых следует два пробела (чтобы Emacs мог сказать, где заканчивается одно предложение и начинается другое).
Для длинных или сложных условных выражений препроцессора каждый #else
и #endif
должен иметь комментарий, объясняющий условие для кода ниже (для #else
) или выше (для #endif
).
Файлы
Эти стандарты требуют , чтобы все программы будут иметь возможность работать , когда /usr
и /etc
будут установлены только для чтения. Таким образом, файлы, модифицированные для внутренних целей (лог - файлов, заблокированных файлов, временных файлов и т.д.) не должны храниться в любом /usr
или /etc
. Исключение составляют программы, задача которых - обновлять файлы конфигурации системы в формате /etc
. Другое исключение сделано для хранения файлов в каталоге, когда пользователь явно попросил изменить файл в том же каталоге.
Портативность
Стандарты кодирования GNU определяют проблему переносимости следующим образом: переносимость в мире Unix означает «между Unix»; в программе GNU такая переносимость желательна, но не жизненно важна.
Согласно стандарту, проблемы переносимости очень ограничены, поскольку программы GNU предназначены для компиляции с одним компилятором, компилятором GNU C , и запускаются только в одной системе, которой является система GNU.
Однако есть одна форма проблемы переносимости, а именно тот факт, что в стандарте четко указано, что программа должна работать на разных типах ЦП . В стандарте сказано, что GNU не поддерживает и не будет поддерживать 16-битные системы, но обработка всех различных 32- и 64-битных систем абсолютно необходима.
Критика
Стандарты кодирования GNU в основном используются проектами GNU, хотя их использование не ограничивается только проектами GNU.
Ядро Linux сильно отпугивает этот стиль для кода ядра, и относится к стилю уничижительно: « Во- первых, я хотел бы предложить распечатав копию GNU стандартов кодирования, и НЕ читать Сожги их, это большой символический жест.. ". [2] Стив МакКоннелл в своей книге « Полный код» также советует не использовать этот стиль; он помечает образец кода, который использует его, значком «Coding Horror», символизирующим особо опасный код, и заявляет, что он затрудняет читаемость, требуя дополнительного уровня отступа для фигурных скобок. [3]
Смотрите также
Рекомендации
- ^ «Стандарты кодирования GNU» . www.gnu.org . Проверено 29 ноября 2020 .
- ^ «Стиль кодирования ядра Linux - документация ядра Linux» . www.kernel.org . Проверено 12 октября 2017 .
- ^ МакКоннелл, Стив (2004). Code Complete: Практическое руководство по созданию программного обеспечения . Редмонд, Вашингтон: Microsoft Press. С. 746–747 . ISBN 0-7356-1967-0.