Вам трудно удерживать до 80 столбцов с Python?

Ответ 1

"Глупая последовательность - это хобгоблин маленьких умов, обожаемый маленькими государственными деятелями, философами и богословами".

Важная часть - "глупо".

Ограничение на 80 столбцов, как и другие части PEP 8, является довольно сильным предложением. Но есть предел, за которым его можно было бы считать глупой консистенцией.

В Komodo есть направляющие отступа и крайняя линия. Таким образом, я знаю, когда закончил. Вопросы "почему?" и "стоит ли его исправлять?"

Вот наши общие ситуации.

протоколирование сообщений. Мы стараемся сделать их легко обернутыми. Они выглядят так:

logger.info( "unique thing %s %s %s",
   arg1, arg2, arg3 )

выражения фильтра Django. Это может продолжаться, но это хорошо. Мы часто вязать несколько фильтров вместе подряд. Но это не должна быть одна строка кода, несколько строк могут сделать более понятным, что происходит.

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

Unit Test Ожидаемые строки результата. Это происходит потому, что мы вырезаем и вставляем для создания кода unit test и не тратим много времени на его рефакторинг. Когда это нас пугает, мы вытаскиваем строки в отдельные строковые переменные и очищаем строки self.assertXXX().

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

У нас редко бывает много функциональных долговечных выражений. Когда мы это делаем, мы не смущаемся, чтобы разбить их и оставить промежуточный результат. Если бы мы были функциональными пуристами, мы могли бы иметь газ с промежуточными переменными результата, но мы не пуристы.

Ответ 2

Я рекомендую стараться оставаться верным 80-столбце, но не любой ценой. Иногда, как и для протоколирования сообщений, просто имеет смысл держать их длиннее, чем разрушать. Но для большинства случаев, таких как сложные условия или понимание списков, расщепление - хорошая идея, потому что это поможет вам разделить сложную логику на более понятные части. Это проще понять:

print sum(n for n in xrange(1000000) 
             if palindromic(n, bits_of_n) and palindromic(n, digits))

чем:

print sum(n for n in xrange(1000000) if palindromic(n, bits_of_n) and palindromic(n, digits))

Это может выглядеть так же, если вы только что написали его, но через несколько дней эти длинные строки становятся трудно понять.

Наконец, хотя PEP 8 диктует ограничение столбца, он также говорит:

Руководство по стилю - это последовательность. Согласованность с этим руководством по стилю это важно. Согласованность в рамках проекта более важна. Согласованность внутри одного модуля или функции наиболее важна.

Но самое главное: знать, когда быть непоследовательным - иногда руководство стиля просто не применяется. Когда вы сомневаетесь, используйте свое лучшее суждение. Посмотрите на другие примеры и решите, что выглядит лучше всего. И не стесняйтесь спросить!

Ответ 3

Не важно, какой именно год или какие устройства вывода вы используете (в некоторой степени). Ваш код должен быть доступен, если это возможно, людьми. Человеку трудно читать длинные строки.

Это зависит от содержания строки, как долго она должна быть. Если это сообщение журнала, то его длина меньше. Если это сложный код, то его большая длина не поможет понять его.

Ответ 4

Временные переменные. Они решают почти каждую проблему с длинными линиями. Очень иногда мне нужно использовать дополнительные парады (например, в более длинном if-statement). Я не буду приводить аргументы за или против 80 символов, поскольку это кажется неуместным.

В частности, для сообщения журнала; вместо:

self._log.info('Insert long message here')

Использование:

msg = 'Insert long message here'
self._log.info(msg)

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

obj.some_long_method_name(subtotal * (1 + tax_rate))

Использование:

grand_total = subtotal * (1 + tax_rate)
obj.some_long_method_name(grand_total)

Большая часть каждой длинной строки, которую я видел, пытается сделать больше, чем одно, и тривиально вытащить одну из этих вещей в временную переменную. Основное исключение - очень длинные строки, но обычно вы можете там что-то делать, поскольку строки в коде часто структурированы. Вот пример:

br = mechanize.Browser()
ua = '; '.join(('Mozilla/5.0 (Macintosh', 'U', 'Intel Mac OS X 10.4',
                'en-US', 'rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6'))
br.addheaders = [('User-agent', ua)]

Ответ 5

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

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

Вот некоторые из вещей, которые я помню, пытаясь ограничить длину моих строк:

• - это код, который я ожидаю от других людей? Если да, то какой стандарт, который эти люди используют и используют для этого типа кода?
• У этих людей есть ноутбуки, используются гигантские шрифты или есть другие причины, по которым их экранная недвижимость ограничена?
• код лучше выглядит для меня разбитым на несколько строк или на одну длинную строку?

Это стилистический вопрос, но стиль действительно важен, потому что вы хотите, чтобы люди читали и понимали ваш код.

Ответ 6

Количество столбцов 80 - это одно из немногих мест, в которых я не согласен с руководством по стилю Python. Я бы рекомендовал вам взглянуть на аудиторию для вашего кода. Если все, с кем вы работаете, использует современную IDE на мониторе с разумным разрешением, это, вероятно, не стоит вашего времени. Мой монитор дешев и имеет относительно слабую разрешающую способность, но я все еще могу поместить 140 столбцов плюс полосы прокрутки, маркеры линий, маркеры разметки и отдельный рамку дерева слева.

Тем не менее, вы, вероятно, в конечном итоге выполните какой-то предел, даже если это не фиксированное число. За исключением сообщений и протоколирования, длинные строки трудно читать. Линии, которые разбиты, также труднее читать. Судите каждую ситуацию самостоятельно и делайте то, что, по вашему мнению, сделает жизнь проще всего для человека, следующего за вами.

Ответ 7

Я бы посоветовал пойти за пределы 80 столбцов. 80 столбцов - это отсрочка, когда это был жесткий предел, основанный на различных устройствах вывода.

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

EDIT: Другие ответы также разъясняют это: важно, что вы нарушаете. Строки чаще всего могут быть "особыми случаями", в которых вы можете немного сгибать правила для ясности. Если ваш код, с другой стороны, становится длинным, это хорошее время, чтобы посмотреть, где логично разбить его.

Ответ 8

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

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

Ответ 9

Приклеивание до 80 столбцов важно не только для удобства чтения, но и потому, что многим из нас нравится иметь узкие оконные окна, чтобы в то же время, что и мы, мы также можем видеть такие вещи, как документация модуля, загружаемая в наш веб-браузер и сообщение об ошибке, сидящее в xterm. Предоставление всего экрана в вашу среду IDE является довольно примитивным, если не монотонным, способом использования пространства экрана.

Как правило, если строка простирается до более чем 80 столбцов, это означает, что что-то пойдет не так: либо вы пытаетесь сделать слишком много в одной строке, либо позволили части вашего кода стать слишком глубокими отступами. Я редко нахожу, что попадаю на правый край экрана, если я также не могу реорганизовать то, что должно быть отдельными функциями; назвать временные результаты; и в других случаях подобное облегчит тестирование и отладку. Прочитайте руководство по стилю кодирования Linus Kernel для хороших точек на эту тему, хотя и с точки зрения C:

http://www.kernel.org/doc/Documentation/CodingStyle

И всегда помните, что длинные строки могут быть разбиты на более мелкие куски:

print ("When Python reads in source code"
       " with string constants written"
       " directly adjacent to one another"
       " without any operators between"
       " them, it considers them one"
       " single string constant.")

Или, если они действительно длинны, они обычно лучше всего определяются как константа, а затем используются в вашем коде под этим сокращенным именем:

STRING_MESSAGE = (
        "When Python reads in source code"
        " with string constants written directly adjacent to one"
        " another without any operators between them, it considers"
        " them one single string constant.")

...
print STRING_MESSAGE
...

Ответ 10

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

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

Ответ 11

Ограничения на 80 символов? В каком году?

Сделайте свой код доступным для чтения. Если длинная строка читаема, она прекрасна. Если это трудно читать, разделите его.

Например, я стараюсь создавать длинные строки, когда есть вызов метода с большим количеством аргументов, и аргументы являются нормальными аргументами, которые вы ожидаете. Итак, скажем, я передаю 10 переменных вокруг кучи методов. Если каждый метод принимает идентификатор транзакции, идентификатор заказа, идентификатор пользователя, номер кредитной карты и т.д., И они хранятся в соответствующих им переменных, то это нормально, чтобы вызов метода отображался в одной строке со всеми переменными один после другой, потому что сюрпризов нет.

Если, однако, вы имеете дело с несколькими транзакциями в одном методе, вам нужно убедиться, что следующий программист может видеть, что ЭТОТ время, когда вы используете transId1, и THAT time transId2. В этом случае убедитесь, что он очищен. (Примечание: иногда с использованием длинных строк тоже появляется).

Просто потому, что "руководство по стилю" говорит, что вы должны что-то делать, это не значит, что вам нужно это делать. Некоторые руководства по стилям просто неправильны.

Ответ 12

Я запускаю код, который время от времени проливает 79 столбцов. Я либо разбил их на "\" (хотя недавно я читал об использовании скобок вместо предпочтительной альтернативы, поэтому я дам этот снимок), или просто пусть это будет, если это не более 15 или так прошло. И это исходит от кого-то, кто отступает только 2, а не 4 пробела (я знаю, стыдно за меня: \)! Это не совсем наука. Это также стиль части, а иногда, хранение вещей на одной линии просто легче управлять или читать. В других случаях чрезмерная прокрутка между сторонами может быть хуже.

Значительная часть времени имеет отношение к более длинным именам переменных. Для переменных вне temp-значений и итераторов я не хочу сокращать их до 1-5 букв. Они длиной от 7 до 15 символов действительно предоставляют контекст в отношении их использования и классов, на которые они ссылаются.

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

Ответ 13

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

PEP 8 - это руководство по стилю для библиотек, входящих в стандартную библиотеку Python. Он никогда не собирался восприниматься как правила стиля для всего кода Python. Тем не менее, нет причин, по которым люди не должны его использовать, но это определенно не набор жестких правил. Как и любой стиль, нет единого правильного пути, и самое главное - это последовательность.