Вам сложно сохранить до 80 столбцов с помощью Python?

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

Как большинство людей с этим справляется?

Ответов (13)

Решение

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

Важная часть - «глупая».

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

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

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

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

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

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

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

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

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

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

Я рекомендую стараться оставаться верным 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 диктует ограничение столбца, он также говорит:

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

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

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

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

РЕДАКТИРОВАТЬ: Другие ответы также проясняют это: важно, что вы нарушаете. Строки чаще могут быть «особыми случаями», когда вы можете немного изменить правила для ясности. С другой стороны, если ваш код становится длинным, самое время посмотреть, где его логично разбить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ограничение на 80 символов? Какой сейчас год?

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

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

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

То, что «руководство по стилю» говорит, что вы должны что-то делать, не означает, что вы должны это делать. Некоторые руководства по стилю просто ошибаются .

Временные переменные. Они решают почти все мои проблемы с длинными очередями. Иногда мне нужно использовать дополнительные скобки (например, в более длинном if-выражении). Я не буду приводить никаких аргументов за или против ограничения 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)]

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

Как правило, если строка растягивается до более чем 80 столбцов, это означает, что в любом случае что-то идет не так: либо вы пытаетесь сделать слишком много в одной строке, либо допустили слишком глубокий отступ части кода. Я редко замечаю, что попадаю в правый край экрана, за исключением случаев, когда мне не удается реорганизовать то, что должно быть отдельными функциями; назвать временные результаты; и делать другие подобные вещи, в конце концов, значительно упростит тестирование и отладку. Прочтите руководство Линуса по стилю кодирования ядра, чтобы узнать о хороших моментах по этой теме, хотя и с точки зрения 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
...

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

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

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