Как убрать отступ в python

Советы Google по кодированию на языке Python. Часть вторая: советы по форматированию исходного кода

Python Style Rules

Точки с запятой

Длина строки

Исключения

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

Что касается комментариев, располагайте длинный URL, если это необходимо, на одной строке.

Обратите внимание на отступ элемента в строке выше (смотрите раздел про отступы, чтобы получить разъяснения).

Скобки

Не используйте их (скобки) с выражением return или с условной конструкцией, если не требуется организовать перенос строки. (Смотрите выше). Однако скобки хорошо использовать для создания кортежей.

Отступы

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

Пустые строки

Пробелы

Никаких пробелов внутри каких-либо скобок.
Хорошо: spam(ham[1], , [])
Плохо: spam( ham[ 1 ], < eggs: 2 >, [ ] )

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

Комментарии

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

Строки документации.

Python имеет уникальный стиль комментирования — строки документации. Строка документации это строка, которая является первой конструкцией в пакете, модуле, классе или функции. Такие строки могут быть экспортированы автоматически с помощью атрибута объекта __doc__ и используются pydoc-ом. (Попробуйте запустить pydoc на своем модуле, чтобы увидеть как это выглядит.) Наше соглашение по строкам документации велит использовать три двойные кавычки для обрамления такой строки. Строки документации должны быть организованы как суммарная строка (одна физическая строка), сносящаяся по кол-ву символов, знаку вопроса или восклицательному знаку, следующим за пустой строкой, а затем остальные строки документации с позиции курсора в качестве первой кавычки первой строки. Ниже описано еще больше информации по оформлению строк документирования.

Модули

Каждый файл должен содержать в себе шаблон лицензии. Выберите подходящий шаблон лицензии для вашего проекта.(Например, Apache 2.0, BSD, LGPL, GPL).

Функции и методы

Классы

Классы должны иметь строку документации ниже своего объявления. Если Ваш класс имеет публичные атрибуты, они должны быть документированы тут же в разделе Attributes и следовать тому же стилю форматирования, что и раздел Args.

Блоки и инлайновые комментарии

Последнее место, которое должны иметь комментарии — это хитрые места в коде. Если Вы хотите пояснить их в Вашем следующем код-ревью, то вы должны прокомментировать их сейчас. Сложные операции, занимающие несколько строк документации перед ее выполнением. Неявные части должны иметь комментарий в конце строки.

Чтобы улучшить читаемость, такие комменарии должны находиться на расстоянии по меньшей мере 2-х пробелов от кода. С другой стороны, лучше вообще не описывайте код. Преположите, что человек, читающий данный код, знает Python (а не то, что вы пытались делать) лучше, чем Вы.

Классы

Это также касается вложенных классов.

Наследование от класса object необходимо, чтобы позволить свойствам работать правильно, и защитит Ваш код от возможной несовместимости с Python 3000. В нем так же определяются специальные методы, которые реализуют стандартную семантику объекта, например: __new__, __init__, __delattr__, __getattribute__, __setattr__, __hash__, __repr__, и __str__.

Строки

Используйте оператор % для форматирования строк, даже если все параметры являются строками. Тщательно взвесте использование оператора + взамен оператора %.

Избегайте использования операторов + и +=, чтобы сконкатенировать строку при помощи цикла, т.к. строки — это неизменяемый тип данных, такой подход создает ненужные объекты и увеличивает время работы по квадратичному, а не линейному закону. Вместо этого просто добавьте каждую подстроку в список и используйте метод join после того, как цикл завершится ( или записывайте каждую подстроку в буфер cStringIO.StringIO)

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

Файлы и сокеты

Подобные циклу for объекты, которые не поддерживают конструкцию with и используют contextlib.closing()

Старый код, написанный под Python 2.5, может подключить возможность использования конструкции with при помощи импорта «from __future__ import with_statement«.

Комментарий TODO

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

Оформление импортов

Конструкции

Однако вы можете расположить результат текста на той же строке, на которой у Вас рапологается условие. Но это можно сделать только в том случае, когда все выражение помещается на одной строке. В частности, Вы никогда не сможете это сделать с конструкцией try/except, т.к. try и except не могут находиться в одной строке, и Вам доступно помещение в одну строку только с конструкцией if БЕЗ else.
Хорошо:

Контроль доступа

Именование

module_name, package_name, ClassName, method_name, ExceptionName, function_name, GLOBAL_CONSTANT_NAME, global_var_name, instance_var_name, function_parameter_name, local_var_name.

Стили основаны на рекоммендациях Гвидо:

Даже когда файл создавался для того, чтобы быть импортированным, обычный импорт не должен иметь побочных эффектов в виде исполнения функциональной части скрипта. Основная функциональность должна быть заложена в функции main().
В Python, pychecker, pydoc и юнит тестах требуются импортируемые модули. Ваш код должен всегда проверять if __name__ == ‘__main__’ перед исполнением, что означает, что Ваш модуль не будет полностью исполнен при импортировании его в другую программу.

Весь код верхнего уровня будет исполнен, когда модуль будет импортирован. Будьте осторожны и не вызывайте функции, не создавайте объекта и не проводите другого вида операции, которые не должны будут выполняться, когда файл подвергнется проверке с помощью pychecker или будет собираться документация при помощи pydoc.

Заключительные слова

От переводчика

Благодарности

Огромное спасибо squaii за ревью и поиск ошибок.

Заключение

Источник

Python табуляция (отступы)

О дна из особенностей Python — для оформления блоков кода вместо привычных фигурных скобок, как в C, C ++, Java или операторных скобок begin … end как в Pascal, используются отступы (или табуляция).

Подробнее о том, какие есть правила расстановки отступов — рассмотрим далее.

Почему табуляция в Питоне так важна?

Что такое отступ? Говоря простыми словами, это просто добавление пробела перед определенным оператором.

Многим программистам жесткое соблюдение отступов может показаться избыточной мерой. Однако именно из-за строго соблюдения правил форматирования, код на Python — чистый, понятный и аккуратный. Отсюда следующие плюсы 👍:

Отступы в языке Python — это способ указать интерпретатору, что оператор (или целая их группа) — это определенный block-комбинация команд для выполнения задачи.

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

def my_small_function(): # [0 пробелов] определение функции со знаком «:» в конце if a > b: # [4 пробела] начало блока условия, располагается внутри функции return a # [8 пробелов] часть блока if else: # [4 пробела] продолжение блока условия, на том же уровне, что и if return b # [8 пробелов] часть блока else print(my_small_function()) # [0 пробелов] вызов функции вне ее блока

💡 По умолчанию в Python используется 4 пробела в качестве отступа

Однако программист может использовать и другое их количество, но не менее одного.

Что нам говорит PEP8?

Для каждого уровня отступов необходимо использовать по 4 пробела.

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

Примеры кода

👍 Правильное оформление

Расположение закрывающих скобок в конструкциях с многими строками под началом первой строки:

my_list = [ one, two, three, four, five, six, ] result = some_arguments( ‘1’, ‘2’, ‘3’, ‘4’, ‘5’, ‘6’, )

👎 Ошибочное оформление

😐 Выборочное оформление

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

some_list = [ one, two, three, four, five, six, ] res = some_arguments( ‘1’, ‘2’, ‘3’, ‘4’, ‘5’, ‘6’, )

Табуляция или пробелы — что использовать? 🤷‍♂️

Согласно официальной документации, самым предпочтительным способом оформления отступов является использование пробелов, обычно 4

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

Настройка IDE для работы с отступами

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

Рассмотрим, как можно настроить или изменить такие параметры в самых популярных IDE, когда возникает такая необходимость.

PyCharm

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

File → Settings → Editor → Code style → Python

Для настроек параметров есть 3 поля:

VSCode

File → Preferences → Settings

Далее для ускорения в строке поиска ввести tab и установить нужные значения для таких опций:

Ошибки при работе с отступами

При неправильном оформлении отступов интерпретатор Python будет сообщать об ошибках. Таких ошибок может быть несколько, рассмотрим основные.

expected an indented block

Данная ошибка может возникать в случае, когда после оглашения начала блока кода — def, if, while и некоторых других на следующей строке отсутствует отступ. Для ее исправления после начала блока должна быть хотя бы одна вложенная строка с отступом.

Возникает ошибка в том случае, когда перед началом строки есть отступ, но на предыдущей отсутствует оглашение начала блока кода, то есть, нет def, if, elif, else, for или while. Обычно такая ситуация возникает случайно, когда программист ставит слишком много пробелов в начале строки.

Indentationerror: expected an indented block

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

Таким образом, отступы в языке программирования Python, в отличие от многих других, играют такую же важную роль, как и служебные слова, так как именно они определяют создание блоков кода. Для каждого indent рекомендуется использовать 4 пробела, однако программист по своему желанию может установить и другое их количество, главное — одинаковое во всем проекте.

Источник

3. Руководство по оформлению программ на Python¶

Author: Guido van Rossum
Оригинальная статья на английском: http://www.python.org/doc/essays/styleguide.html Python Style Guide
Перевод выполнен компанией «Калкулэйт».

Общие замечания¶

Разметка¶

Отступы¶

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

Табуляция или пробелы?¶

Максимальная длина строки¶

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

Пустые строки¶

Отделяйте функции верхнего уровня и объявления классов двумя пустыми строками. Определения методов внутри класса отделяются одной пустой строкой. Дополнительно пустые строки можно использовать для отделения групп родственных функций. Пустые строки можно опускать внутри связки из одностроковых определений (набора абстрактных методов).
Если пустые строки используются для отделения методов в классе, то вставляйте также пустую строку между строкой «class. » и определением первого метода.
Используйте пустые строки в функциях для указания логических блоков, но не переусердствуйте.

Пробелы в выражениях и операторах¶

Другие рекомендации¶

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

Не используйте пробелы вокруг знака ‘=’ в случае указания значения по умолчанию:

Комментарии¶

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

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

Используйте два пробела после точки в конце предложения.

Блоковые комментарии¶

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

Внутристроковые комментарии¶

Внутристроковые комментарии излишни и отвлекают, если их значение и так очевидно:

Но иногда может быть полезно:

Строки документации¶

Все модули, как правило, имеют строки документации. Все функции и классы, экспортируемые из модуля, также должны иметь строки документации.
Публичные методы (включая конструктор init) тоже должны иметь строки документации.

Всегда используйте «»»тройные сдвоенные кавычки»»» для выделения строк документации.

Одностроковые

Многостроковые

Начинаются одной обобщающей строкой, за которой следует пустая строка и более полное описание.

Рекомендуется перед закрывающими тройными кавычками вставлять пустую строку.
Каждый аргумент лучше начинать с новой строки и отделять от описания двумя тире:

Поддержка контроля версий

Если вы используете RCS или CVS, то пишите следующим образом:

Вставляйте это после строк документации перед началом кода, отделяя сверху и снизу пустой строкой.

Именование¶

Стили именования¶

Стили предписаний¶

Названия модулей

Имена модулей можно писать в стиле «MixedCase» или «lowercase».
Модули, которые экспортируют один класс, обычно называют в стиле MixedCase, а имя модуля совпадает с именем класса (например, стандартный модуль StringIO).
Модули, которые экспортируют множество функций, обычно называют в стиле lowercase.

Class Names

Имена классов обычно используют стиль «CapWords». Классы для внутреннего пользования начинаются с подчеркивания.

Источник

Правила оформления Python-кода

1. Отступы

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

2. Точки с запятой

Не разделяйте ваши строки с помощью точек с запятой и не используйте точки с запятой для разделения команд, находящихся на одной строке.

3. Скобки

Используйте скобки экономно. Не используйте их с выражением return или с условной конструкцией, если не требуется организовать перенос строки. Однако скобки хорошо использовать для создания кортежей.

4. Пробелы в выражениях и инструкциях

4.1 Пробелы и скобки

4.1.1 Не ставьте пробелы внутри каких-либо скобок (обычных, фигурных и квадратных).

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

Хорошо Плохо Хорошо Плохо

4.2 Пробелы рядом с запятой, точкой с запятой и точкой

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

4.3 Пробелы вокруг бинарных операторов

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

5. Длина строк

Ограничивайте длину строк 79 символами (а длину строк документации и комментариев — 72 символами). В общем случае не используйте обратный слеш в качестве перехода на новую строку. Используйте доступное в Python явное объединение строк посредством круглых и фигурных скобок. Если необходимо, можно добавить дополнительную пару скобок вокруг выражения.

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

Что касается длинных URL в комментариях, то располагайте их, если это необходимо, на одной строке.

Обратный слеш иногда используется. Например, с длинной конструкцией with для переноса блока инструкций.

6. Пустые строки

Отделяйте функции (верхнего уровня, не функции внутри функций) и определения классов двумя пустыми строками. Определения методов внутри класса отделяйте одной пустой строкой. Две пустые строки должны быть между объявлениями верхнего уровня, будь это класс или функция. Одна пустая строка должна быть между определениями методов и между объявлением класса и его первым методом.

Используйте (без энтузиазма) пустые строки в коде функций, чтобы отделить друг от друга логические части.

Python расценивает символ control+L как незначащий (whitespace), и вы можете использовать его, потому что многие редакторы обрабатывают его как разрыв страницы — таким образом, логические части в файле будут на разных страницах. Однако не все редакторы распознают control+L и могут на его месте отображать другой символ.

7. Имена

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

7.1 Имена функций

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

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

7.2 Имена модулей и пакетов

Модули должны иметь короткие имена, состоящие из маленьких букв. Можно использовать символы подчёркивания, если это улучшает читабельность. То же самое относится и к именам пакетов, однако в именах пакетов не рекомендуется использовать символ подчёркивания.

Так как имена модулей отображаются в имена файлов, а некоторые файловые системы являются нечувствительными к регистру символов и обрезают длинные имена, очень важно использовать достаточно короткие имена модулей — это не проблема в Unix, но, возможно, код окажется непереносимым в старые версии Windows, Mac, или DOS.

7.3 Имена классов

Все имена классов должны следовать соглашению CapWords почти без исключений.

Иногда вместо этого могут использоваться соглашения для именования функций, если интерфейс документирован и используется в основном как функции.

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

Так как исключения являются классами, к исключениями применяется стиль именования классов. Однако вы можете добавить Error в конце имени (если, конечно, исключение действительно является ошибкой).

7.4 Имена констант

Константы обычно объявляются на уровне модуля и записываются только заглавными буквами, а слова разделяются символами подчеркивания.

8. Комментарии

Комментарии, противоречащие коду, хуже, чем отсутствие комментариев. Всегда исправляйте комментарии, если меняете код!

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

Ставьте два пробела после точки в конце предложения.

Если вы — программист, не говорящий по-английски, то всё равно следует использовать английский язык для написания комментариев. Особенно, если нет уверенности на 120% в том, что этот код будут читать только люди, говорящие на вашем родном языке.

8.1 Блоки комментариев

Блок комментариев обычно объясняет код (весь или только некоторую часть), идущий после блока, и должен иметь тот же отступ, что и сам код. Каждая строчка такого блока должна начинаться с символа # и одного пробела после него (если только сам текст комментария не имеет отступа).

8.2 Комментарии в строке с кодом

Старайтесь реже использовать подобные комментарии.

Такой комментарий находится в той же строке, что и инструкция. «Встрочные» комментарии должны отделяться хотя бы двумя пробелами от инструкции. Они должны начинаться с символа # и одного пробела.

Комментарии в строке с кодом не нужны и только отвлекают от чтения, если они объясняют очевидное.

8.3 Строки документации

Соглашения о написании хорошей документации (docstrings) зафиксированы в PEP 257.

Очень важно, чтобы закрывающие кавычки стояли на отдельной строке. А еще лучше, если перед ними будет ещё и пустая строка.

Для однострочной документации можно оставить «»» на той же строке.

9. Циклы

9.1 Циклы по спискам

Если нам необходимо в цикле пройти по всем элементам списка, то хорошим тоном (да и более читаемым) будет такой способ:

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

А если нужно пройти по списку задом наперед, то лучше всего использовать метод reversed:

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

9.2 Циклы по списку чисел

Если есть необходимость пройти в цикле по ряду чисел, то метод range будет намного приемлемее, как минимум потому, что этот метод потребляет намного меньше памяти, чем вариант в блоке «Плохо». А представьте, что у вас ряд из трёх миллиардов последовательных чисел!

9.3 Циклы по спискам с индексами

Метод enumerate позволяет получить сразу индекс и значение из списка, что, во-первых, предоставляет множество возможностей для дальшнейшего проектирования, а во-вторых, такой код легче читается и воспринимается.

9.4 Циклы по двум спискам

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

10. Импорты

Каждый импорт, как правило, должен быть на отдельной строке.

В то же время, можно писать так:

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

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

Рекомендуется абсолютное импортирование, так как оно обычно более читаемо и ведет себя лучше (или, по крайней мере, даёт понятные сообщения об ошибках), если импортируемая система настроена неправильно (например, когда каталог внутри пакета заканчивается на sys.path ).

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

Следует избегать шаблонов импортов ( from import * ), так как они делают неясным то, какие имена присутствуют в глобальном пространстве имён, что вводит в заблуждение как читателей, так и многие автоматизированные средства.

Рекомендуем также ознакомиться с полной версией соглашения о том, как писать код на Python (PEP 8)

Источник