какова максимальная длина строки кода по pep 8 с комментариями
Разметка кода Python, PEP 8
Разметка кода
Рекомендуется придерживаться следующих правил разметки кода
Отступы:
Используйте 4 пробела для добавления отступа.
Последующие строки обернутых элементов в скобки должны быть выравнены либо по вертикали, либо с помощью висящего отступа.
При использовании висячего отступа, следует учитывать следующее: в первой строке не должно быть аргументов, и следует использовать дополнительный отступ, чтобы четко отличить себя как строку продолжения.
Правильно:
Не правильно:
Правило 4 пробелов не является обязательным для строк продолжения.
По желанию:
Закрывающая скобка в многострочных конструкциях может располагаться либо под первым символом последней строки списка:
или может быть на уровне первого символа строки, которая начинает многострочную конструкцию:
TAB или пробелы?
Пробелы являются предпочтительным методом отступа.
Табуляция должна использоваться исключительно для соответствия с кодом, который уже имеет такие отступы.
Python 3 запрещает смешивать использование табуляции и пробелов для отступа. Код с отступом в виде комбинации символов табуляции и пробелов должен быть преобразован исключительно в пробелы.
Максимальная длина строки с кодом:
Ограничьте все строки максимум 79 символами.
Для строк документации или комментариев длина строки должна быть ограничена 72 символами.
Ограничение ширины окна редактора позволяет одновременно открывать несколько файлов и хорошо работает при использовании инструментов обзора, которые представляют две версии кода в соседних окнах.
Перенос по умолчанию в большинстве редакторов нарушает визуальную структуру кода, что делает его более трудным для понимания. Данные ограничения приняты для того, чтобы избежать автоматического переноса строк в редакторах с шириной окна, установленной на 80 символов, даже если он помещает маркер курсора в последний столбец. Некоторые IDE могут вообще не иметь авто-переноса строк.
Некоторые команды разработчиков предпочитают более длинные строки при написании кода. Исключительно для поддержания такого кода внутри команды, разрешается увеличить ограничение длины строки до 99 символов, при условии, что комментарии и документация должна быть ограничена 72 символами
Стандартная библиотека Python консервативна и требует ограничения строки до 79 символов (и строки документации/комментариев до 72).
Еще один такой случай возможен с assert утверждениями.
Удостоверьтесь, что сделали отступ в 4 пробела для продолжения строки кода.
Перенос строки до или после двоичного оператора?
В течение десятилетий рекомендуется переносить строки после двоичного оператора. Но это может усложнить читабельность. При таком переносе, операторы, как правило, разбросаны по разным столбцам, при этом каждый оператор отошел от своей переменной и перешел на предыдущую строку. Здесь глаз должен сделать дополнительную работу, чтобы увидеть, какие элементы добавляются, а какие вычитаются:
Чтобы решить проблему читаемости, математики следуют противоположному соглашению. Следуя традиции математики, обычно получается более читаемый код:
В коде Python допускается перенос до или после двоичного оператора, если есть такое соглашение. Для нового кода предлагается математический стиль.
Пустые строки:
Определения функций и классов верхнего уровня должны быть заключены в две пустые строки.
Определения методов внутри класса заключены в одну пустую строку.
Дополнительные пустые строки могут использоваться для разделения групп связанных функций. Пустые строки могут быть пропущены между связкой связанных строк (например, набором фиктивных реализаций).
Используйте пустые строки в функциях, чтобы указать логические разделы.
Кодировка файла с кодом:
Код в основном дистрибутиве Python всегда должен использовать UTF-8 (или ASCII в Python 2).
Файлы, использующие ASCII (в Python 2) или UTF-8 (в Python 3), не должны иметь декларации кодировки.
Для Python 3.0 и выше, для стандартной библиотеки предписана следующая политика. Все идентификаторы в стандартной библиотеке Python ДОЛЖНЫ использовать идентификаторы только ASCII и ДОЛЖНЫ использовать английские слова везде, где это возможно (сокращения и технические термины, которые не являются английскими). Кроме того, все строковые литералы и комментарии также должны быть в ASCII.
Единственными исключениями являются:
Проектам с открытым исходным кодом с глобальной аудиторией рекомендуется придерживаться аналогичной политики.
Импорт:
Импорт обычно должен быть в отдельных строках:
Это нормально, хотя:
Импорт всегда помещается вверху файла, сразу после любых комментариев и строк документации, а также перед глобальными переменными и константами модуля.
Импорт должен быть сгруппирован в следующем порядке:
Вы должны поставить пустую строку между каждой группой импорта.
Рекомендуется абсолютный импорт, так как он обычно более читабелен и, как правило, ведет себя лучше (или, по крайней мере, дает лучшие сообщения об ошибках), если система импорта настроена неправильно (например, когда каталог внутри пакета заканчивается в sys.path ):
Однако явный относительный импорт является приемлемой альтернативой абсолютному импорту, особенно когда речь идет о сложном макете в пакете, где использование абсолютного импорта было бы излишне многословным:
Код стандартной библиотеки должен избегать сложных макетов пакетов и всегда использовать абсолютный импорт.
Неявный относительный импорт никогда не должен использоваться и был удален в Python 3.
При импорте класса из модуля, обычно можно записать следующее:
Если это написание вызывает локальные конфликты имен, то запишите импорт через точку:
Следует избегать импорта подстановочных знаков ( from import * ), так как из-за этого неясно, какие имена присутствуют в пространстве имен, запутывает как читателей, так и многие автоматизированные инструменты. Существует один оправданный вариант использования для импорта с использованием подстановочного знака, который заключается в повторной публикации внутреннего интерфейса как части общедоступного API.
При повторной публикации имен, все же применяются приведенные ниже рекомендации, касающиеся открытых и внутренних интерфейсов.
Расположение имен «dunders» в коде:
Кавычки в строках:
В Python одинарные и двойные кавычки функционально одинаковы. PEP не дает рекомендации какие из них предпочтительнее. Выберите правило и придерживайтесь его. Если, например, строка содержит одинарные кавычки, чтобы избежать обратной косой черты в строке, используйте дополнительно двойные кавычки. Это улучшает читаемость.
Для строк с тройными кавычками всегда используйте символы двойной кавычки, чтобы соответствовать соглашению с документированной строкой в PEP 257.
Русские Блоги
Ближе к дому начните изучать стиль программирования Python.
Макет кода
Давайте посмотрим, как выглядит правильный макет кода:
Общий компилятор такого типа макета будет поддерживать автоматическое разрешение, так что вы, вероятно, это знаете.
Давайте посмотрим, как выглядит плохой макет:
Вёрстка оператора if:
Табуляция или пробел
Просто используйте пробелы.
В vim табуляция заменена пробелами, поэтому мне не нужно беспокоиться о ее неправильном использовании.
Максимальная длина строки
В строке можно написать до 79 символов.
Если предложение слишком длинное, рекомендуется его обернуть, что следует сделать после оператора.
Правильная последовательность импорта:
Используйте линию пробела, чтобы различать разные группы
Чаще всего используется метод импорта абсолютного адреса. Не используйте импорт с подстановочными знаками.
Правильно вставляйте пробелы в выражения и утверждения
Напишите составные выражения:
Комментарий
Лучше писать заметки на английском языке.
Интеллектуальная рекомендация
Python3.7 + Django2 Интегрированная модель данных (MySQL8)
Резюме веб-разработки-написание и чтение XML-1
Два аналитических метода: DOM (объектная модель документа) Ключевое слово: Дерево (документ) Преимущества: XML-файл встроен в древовидную структуру в памяти, и узлы можно просматривать и изменят.
Правила оформления кода по PEP8 на Python. Руководство для программиста
Введение в PEP8 (Python Enhancement Proposal #8)
Документ Python Enhancement Proposal #8 (сокращенно РЕР8) содержит предложения по стилевому оформлению кода программ на языке Python. Вообще говоря, вы вправе форматировать свой код так, как считаете нужным. Однако применение единообразного стиля облегчит изучение кода другими людьми и улучшит его удобочитаемость. Совместное использование общего стиля с другими Руthоn-программистами в рамках большого сообщества способствует улучшению качества программ при коллективной работе над проектами. Но даже если единственный человек, который когда-либо будет читать ваш код, — это вы, соблюдение рекомендаций РЕР 8 облегчит внесение последующих изменений в код.
Документ РЕР8 содержит детализированные правила написания кода на Python. По мере развития языка этот документ постоянно обновляется. Было бы неплохо, если бы вы прочитали целиком все руководство
Ниже приведены некоторые правила, которых следует обязательно придерживаться.
Пробелы
В языке Python пробелы имеют синтаксическое значение. Особое значение Pythоn-программисты придают влиянию пробелов на удобочитаемость кода.
Имена
В документе РЕР8 для различных элементов языка предлагается свой стиль имен. Благодаря этому можно легко определить в процессе чтения кода, какому типу соответствует то или иное имя:
Выражения и инструкции
Одно из положений дзен-философии Python гласит: «Должен существовать один — и предпочтительно только один — очевидный способ сделать это». В рекомендациях документа РЕР8 предпринимается попытка кодифицировать такой стиль написания выражений и предложений.
В каждом подразделе модули должны располагаться в алфавитном порядке.
Что следует запомнить
Best Practices Python PEP8 Code Style — Стиль кода для написания функций
Если вы спросите программистов Python, что им больше всего нравится в Python, они часто будут ссылаться на его высокую читабельность. Действительно, высокий уровень читабельности лежит в основе дизайна языка Python, следуя общепризнанному факту, что код читается гораздо чаще, чем пишется.
Одной из причин высокой читабельности кода Python является его полный набор рекомендаций PEP8 по стилю кода и «Pythonic» идиом.
Когда ветеран Python-разработчик (Pythonista) называет части кода не «Pythonic», они обычно означают, что эти строки кода не следуют общим правилам и не выражают свое намерение в том, что считается лучшим (слушайте: наиболее читаемый) путь.
В некоторых случаях не было достигнуто соглашения о том, как выразить намерение в коде Python, но такие случаи редки.
Явный код
Хотя в Python возможен любой вид черной магии, наиболее явный и простой способ предпочтителен.
Плохо
Хорошо
В приведенном выше хорошем коде x и y явно принимаются от вызывающей стороны, и возвращается явный словарь. Разработчик, использующий эту функцию, точно знает, что делать, читая первые и последние строки, что не так с плохим примером.
Одно утверждение на строку
Несмотря на то, что некоторые составные операторы, такие как списочные выражения, допускаются и ценятся за их краткость и выразительность, использование двух разделенных операторов в одной строке кода является плохой практикой.
Плохо
Хорошо
Аргументы функции
Аргументы могут быть переданы в функции четырьмя различными способами.
Программист должен написать функцию, чтобы определить, какие аргументы являются позиционными аргументами, а какие — необязательными аргументами ключевых слов, и решить, использовать ли передовые методы передачи произвольных аргументов. Если следовать приведенному выше совету разумно, можно и приятно писать функции Python, которые:
Избегайте волшебной палочки
Мощный инструмент для хакеров, Python поставляется с очень богатым набором хуков и инструментов, позволяющих вам выполнять практически любые хитрые трюки. Например, можно выполнить каждое из следующих действий:
Тем не менее, все эти варианты имеют много недостатков, и всегда лучше использовать самый простой способ для достижения вашей цели. Основным недостатком является то, что читаемость сильно страдает при использовании этих конструкций. Многие инструменты анализа кода, такие как pylint или pyflakes, не смогут проанализировать этот «волшебный» код.
Мы считаем, что разработчик Python должен знать об этих почти безграничных возможностях, потому что это вселяет уверенность в том, что на пути не будет непроходимых проблем. Однако очень важно знать, как и, в частности, когда их не использовать.
Подобно мастеру кунг-фу, питонист знает, как убивать одним пальцем, и никогда не делать этого на самом деле.
Мы все ответственные пользователи
Как видно выше, Python допускает множество трюков, и некоторые из них потенциально опасны. Хорошим примером является то, что любой клиентский код может переопределять свойства и методы объекта: в Python нет ключевого слова «private». Эта философия, очень отличающаяся от языков с высокой степенью защиты, таких как Java, которые предоставляют множество механизмов для предотвращения любого неправильного использования, выражается высказыванием: «Мы все ответственные пользователи».
Это не означает, что, например, никакие свойства не считаются закрытыми и что правильная инкапсуляция невозможна в Python. Скорее, вместо того, чтобы полагаться на бетонные стены, возводимые разработчиками между их кодом и чужим, сообщество Python предпочитает полагаться на ряд соглашений, указывающих, что к этим элементам не следует обращаться напрямую.
Основное соглашение для частных свойств и деталей реализации заключается в добавлении префикса ко всем «внутренним элементам». Если клиентский код нарушает это правило и получает доступ к этим отмеченным элементам, любое неправильное поведение или проблемы, возникшие при изменении кода, являются ответственностью клиентского кода.
Использование этого соглашения приветствуется: любой метод или свойство, которые не предназначены для использования клиентским кодом, должны начинаться с подчеркивания. Это гарантирует лучшее разделение обязанностей и более легкую модификацию существующего кода; всегда будет возможно обнародовать частную собственность, но сделать публичную собственность частной может быть гораздо более сложной операцией.
Возвращение значения
Когда функция усложняется, нередко используют несколько операторов return внутри тела функции. Однако, чтобы сохранить четкое намерение и устойчивый уровень читабельности, желательно избегать возврата значимых значений из многих выходных точек в теле.
Существует два основных случая возврата значений в функцию: результат возврата функции, когда она была обработана нормально, и случаи ошибок, которые указывают на неправильный входной параметр, или любую другую причину, по которой функция не может завершить вычисление или задача.
Если вы не хотите вызывать исключения для второго случая, может потребоваться возврат значения, такого как None или False, указывающего, что функция не может работать правильно. В этом случае лучше вернуться, как только был обнаружен неправильный контекст. Это поможет сгладить структуру функции: весь код после оператора return-from-of-error может предполагать, что условие выполнено для дальнейшего вычисления основного результата функции. Наличие нескольких таких операторов возврата часто необходимо.
Однако, когда функция имеет несколько основных точек выхода для своего нормального хода, становится трудно отлаживать возвращаемый результат, поэтому может быть предпочтительнее сохранить одну точку выхода. Это также поможет выделить некоторые пути кода, а несколько точек выхода являются вероятным признаком того, что такой рефакторинг необходим.
Идиомы
Хотя обычно есть один — и предпочтительно только один — очевидный способ сделать это; способ писать идиоматические коды Python могут быть неочевидными для начинающего Python. Таким образом, хорошие идиомы должны быть осознанно приобретены.
Ниже приведены некоторые распространенные идиомы Python:
Распаковка
Если вы знаете длину списка или кортежа, вы можете назначить имена его элементам при распаковке. Например, поскольку enumerate() будет предоставлять кортеж из двух элементов для каждого элемента в списке:
Вы также можете использовать это для замены переменных:
Вложенная распаковка тоже работает:
Создать игнорируемую переменную
Если вам нужно что-то назначить (например, в распаковке ), но вам не понадобится эта переменная, используйте __ :
Многие руководства по стилю Python рекомендуют использовать одно подчеркивание « _ » для одноразовых переменных, а не двойное подчеркивание « __ », рекомендованное здесь.Проблема заключается в том, что « _ » обычно используется в качестве псевдонима для gettext() функции, а также в интерактивном приглашении для хранения значения последней операции.Вместо этого использование двойного подчеркивания является столь же понятным и почти таким же удобным, и исключает риск случайного вмешательства в любой из этих других случаев использования.
Создайте список длины N того же самого
Используйте * оператор списка Python :
Создание списка длины N списков
Поскольку списки являются изменяемыми, * оператор (как указано выше) создаст список из N ссылок на один и тот же список, что вряд ли вам нужно. Вместо этого используйте понимание списка:
Примечание: используйте range () вместо xrange () в Python 3.
Создать строку из списка
Распространенная идиома для создания строк — использовать str.join() пустую строку.
Это установит значение переменной word в «spam». Эта идиома может применяться к спискам и кортежам.
Поиск предмета в коллекции
Иногда нам нужно искать в коллекции вещей. Давайте рассмотрим два варианта: списки и наборы.
Возьмите следующий код для примера:
Из-за этих различий в производительности часто рекомендуется использовать наборы или словари вместо списков в случаях, когда:
Для небольших коллекций или коллекций, в которых вы не часто будете искать, дополнительное время и память, необходимые для настройки хэш-таблицы, часто будут больше, чем время, сэкономленное благодаря улучшенной скорости поиска.
Дзен питона
Соглашения PEP8
Вот некоторые соглашения, которым вы должны следовать, чтобы сделать ваш код легче для чтения.
Проверьте, равна ли переменная постоянной
Вам не нужно явно сравнивать значение с True, None или 0 — вы можете просто добавить его в оператор if. См. Проверка истинности значения для получения списка того, что считается ложным.
Плохо :
Хорошо :
Доступ к элементу словаря
Плохо :
Хорошо :
Короткие способы манипулирования списками
Постижения списков предоставляют мощный и лаконичный способ работы со списками.
Выражения генератора следуют почти тому же синтаксису, что и списки, но возвращают генератор вместо списка.
Создание нового списка требует больше работы и использует больше памяти. Если вы просто собираетесь пройтись по новому списку, используйте вместо этого итератор.
Плохо :
Хорошо :
Используйте списки, когда вам действительно нужно создать второй список, например, если вам нужно использовать результат несколько раз.
Если ваша логика слишком сложна для понимания короткого списка или выражения генератора, рассмотрите возможность использования функции генератора вместо возврата списка.
Хорошо :
Никогда не используйте списочное понимание только для его побочных эффектов.
Плохо :
Хорошо :
Фильтрация списка
Плохо :
Никогда не удаляйте элементы из списка, пока вы просматриваете его.
Не делайте несколько проходов по списку.
Хорошо :
Используйте понимание списка или выражение генератора.
Возможные побочные эффекты изменения исходного списка
Изменение исходного списка может быть рискованным, если на него ссылаются другие переменные. Но вы можете использовать назначение срезов, если вы действительно хотите это сделать.
Изменение значений в списке
Плохо :
Помните, что назначение никогда не создает новый объект. Если две или более переменных ссылаются на один и тот же список, изменение одной из них изменит их все.
Хорошо :
Безопаснее создать новый объект списка и оставить оригинал в покое.
Используйте enumerate() счетчик вашего места в списке.
Читать из файла
Используйте синтаксис для чтения из файлов. Это автоматически закроет файлы для вас. with open
Плохо :
Хорошо :
Продолжение строки
Когда логическая строка кода длиннее допустимого предела, вам необходимо разбить ее на несколько физических строк. Интерпретатор Python объединяет последовательные строки, если последний символ строки является обратной косой чертой. Это полезно в некоторых случаях, но, как правило, его следует избегать из-за его хрупкости: пробел, добавленный в конец строки после обратной косой черты, нарушит код и может привести к неожиданным результатам.
Лучшее решение — использовать круглые скобки вокруг ваших элементов. Оставленный с незакрытой круглой скобкой в конце строки, интерпретатор Python присоединится к следующей строке, пока круглые скобки не будут закрыты. То же самое относится и к фигурным и квадратным скобкам.
Плохо :
Хорошо :
Однако чаще всего разделение длинной логической строки является признаком того, что вы пытаетесь сделать слишком много вещей одновременно, что может ухудшить читабельность.
Почему в PEP-8 указана максимальная длина строки в 79 символов? [закрыто]
Почему в этом тысячелетии Python PEP-8 должен указывать максимальную длину строки в 79 символов?
Практически каждый редактор кода под солнцем может обрабатывать более длинные строки. Что делать с упаковкой, должно быть выбором потребителя контента, а не ответственностью создателя контента.
Есть ли (законно) веские причины для присоединения к 79 персонажам в этом возрасте?
Большая часть ценности PEP-8 состоит в том, чтобы не давать людям спорить о несущественных правилах форматирования и продолжать писать хороший, последовательно отформатированный код. Конечно, никто на самом деле не думает, что 79 является оптимальным, но нет очевидного выигрыша в его изменении на 99 или 119 или любой другой предпочтительной длине линии. Я думаю, что выбор таков: следуйте правилу и найдите достойную причину для борьбы или предоставьте некоторые данные, которые демонстрируют, как удобочитаемость и производительность зависят от длины строки. Последнее было бы чрезвычайно интересно и имело бы хорошие шансы изменить мнение людей, я думаю.
Обеспечение читабельности вашего кода, а не только машинного. Многие устройства по-прежнему могут отображать только 80 символов одновременно. Кроме того, это позволяет людям с большими экранами выполнять несколько задач за счет возможности установки нескольких окон рядом друг с другом.
Читаемость также является одной из причин принудительного отступа строки.
Я программист, который ежедневно сталкивается с большим количеством кода. Открытый исходный код и что было разработано в доме.
Как программист, я считаю полезным открывать много исходных файлов одновременно и часто организовывать мой рабочий стол на моем (широкоэкранном) мониторе так, чтобы два исходных файла располагались рядом. Я мог бы программировать на обоих или просто читать одно и программировать на другое.
Я нахожу это неудовлетворительным и разочаровывающим, когда один из этих исходных файлов имеет ширину> 120 символов, потому что это означает, что я не могу удобно разместить строку кода на строке экрана. Это нарушает форматирование для переноса строк.
Я говорю «120», потому что это уровень, до которого меня раздражает, когда код шире. После такого количества символов вы должны разделить строки для удобства чтения, не говоря уже о стандартах кодирования.
Я пишу код с учетом 80 столбцов. Это просто для того, чтобы когда я протекал через эту границу, это не так уж плохо.