Советы по стилю C для линии <80 символов - PullRequest
4 голосов
/ 05 февраля 2011

Я не могу найти много рекомендаций / руководств по стилю для C, в которых упоминается, как разбивать строки в C, чтобы у вас было менее 80 символов в строке.

Единственное, что я могу найти, это PEP 7 , руководство по стилю для основной реализации Python ( CPython ).

Существует ли ссылка на всеобъемлющее руководство по стилю C, содержащее рекомендации по переносу?

Или, если это не удастся, хоть какой-нибудь хороший личный совет по этому вопросу?

PS: Что вы делаете с действительно_long_variable_names_that_go_on_forever (помимо сокращения)?Вы кладете их на левый край или позволяете разлиться?

Ответы [ 4 ]

5 голосов
/ 05 февраля 2011

Вот Оригинальная статья Линуса о (linux) стиле кодирования ядра. Документ, вероятно, эволюционировал, поскольку он является частью исходного кода .

3 голосов
/ 05 февраля 2011

Вы можете взглянуть на Стандарты кодирования GNU , который охватывает гораздо больше, чем стиль кодирования, но тем не менее довольно интересен.

1 голос
/ 05 февраля 2011

80 символов в строке "правило" устарели.

http://richarddingwall.name/2008/05/31/is-the-80-character-line-limit-still-relevant/

http://en.wikipedia.org/wiki/Characters_per_line

http://news.ycombinator.com/item?id=180949

Мы больше не используем перфокарты . У нас огромные дисплеи с большими разрешениями, которые со временем будут только увеличиваться (очевидно, портативные устройства, планшеты и нетбуки являются важной частью современных вычислений, но я думаю, что большинство из нас программируют на настольных компьютерах и ноутбуках, и даже ноутбуки имеют большие дисплеи в эти дни).

Вот правила, которые, по моему мнению, мы должны учитывать:

Одна строка кода делает одну вещь.

Одна строка кода записывается как Одна строка кода .

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

Некоторые люди считают, что определенные языки поощряют сложные «однострочные». Perl - это пример языка, который, как полагают некоторые, является языком «пиши один раз, никогда не читай», но знаете что? Если вы не пишете запутанный Perl, если вместо этого вы делаете одну вещь в строке, код Perl может быть столь же управляемым, как и все остальное ... хорошо, возможно, не APL ;)

Помимо сложных однострочников, другой недостаток, который я вижу в соответствии с неким искусственным ограничением символов, - это сокращение идентификаторов для соответствия правилу. Описательные идентификаторы, которые не содержат аббревиатур и сокращений, часто более понятны, чем сокращенные альтернативы. Четкие идентификаторы приближают нас к грамотному программированию .

Возможно, лучший «современный» аргумент, который я слышал о сохранении ограничения на число символов 80 или другого значения, - это «параллельное» сравнение кода. Параллельное сравнение полезно для сравнения разных версий одного и того же исходного файла, как в операциях слияния системы контроля версий исходного кода . Лично я заметил, что если я буду соблюдать правила, которые я предложил, большинство моих строк кода будет достаточно коротким, чтобы просматривать их полностью, когда два исходных файла (или даже три, для трехсторонних слияний) смотреть бок о бок на современном дисплее. Конечно, некоторые из них заполнили окно просмотра. В таких случаях я просто прокручиваю немного, если мне нужно увидеть больше. Кроме того, современные инструменты сравнения могут легко сказать, какие линии различаются, поэтому вы знаете, на какие линии вы должны смотреть. Если ваш инструментарий говорит вам, что нет никакой причины для прокрутки, то нет никакой причины для прокрутки.

0 голосов
/ 05 февраля 2011

Я думаю, что старая рекомендация в 80 символов на строку исходит из того времени, когда мониторы были 80x25, в настоящее время должно подойти 128 или более.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...