Ошибка e302 python - Исправление ошибок и поиск оптимальных решений проблем

I’m using vim editor as python IDE. Below is a simple python program to calculate square root of a number:

import cmath
def sqrt():
    try:
        num = int(input("Enter the number : "))
        if num >= 0:
            main(num)
        else:
            complex(num)
    except:
        print("OOPS..!!Something went wrong, try again")
        sqrt()
    return

def main(num):
    squareRoot = num**(1/2)
    print("The square Root of ", num, " is ", squareRoot)
    return

def complex(num):
    ans = cmath.sqrt(num)
    print("The Square root if ", num, " is ", ans)
    return

sqrt()

And the warnings are :

1-square-root.py|2 col 1 C| E302 expected 2 blank lines, found 0 [pep8]
1-square-root.py|15 col 1 C| E302 expected 2 blank lines, found 1 [pep8]
1-square-root.py|21 col 1 C| E302 expected 2 blank lines, found 0 [pep8]

Can you please tell why these warnings are coming?

renatodamas

14.4k6 gold badges33 silver badges47 bronze badges

asked Nov 1, 2015 at 20:30

Amit UpadhyayAmit Upadhyay

7,0214 gold badges43 silver badges56 bronze badges

import cmath


def sqrt():
    try:
        num = int(input("Enter the number : "))
        if num >= 0:
            main(num)
        else:
            complex_num(num)
    except:
        print("OOPS..!!Something went wrong, try again")
        sqrt()
    return


def main(num):
    square_root = num**(1/2)
    print("The square Root of ", num, " is ", square_root)
    return


def complex_num(num):
    ans = cmath.sqrt(num)
    print("The Square root if ", num, " is ", ans)
    return

sqrt()

The previous will fix your PEP8 problems. After your import you need to have 2 new lines before starting your code. Also, between each def foo() you need to have 2 as well.

In your case you had 0 after import, and you had 1 newline between each function. Part of PEP8 you need to have a newline after the end of your code. Unfortunately I don’t know how to show it when I paste your code in here.

Pay attention to the naming, it’s part of PEP8 as well. I changed complex to complex_num to prevent confusion with builtin complex.

In the end, they’re only warning, they can be ignored if needed.

answered Nov 1, 2015 at 21:06

You need to give two blank lines between meaningful code blocks.

These include (for example):

The import block
Each function

8bitjunkie

12.6k9 gold badges54 silver badges70 bronze badges

answered Aug 9, 2017 at 9:59

Here is the link to the documentation:
PEP8 Style Guide for Python
You should add two spaces between the functions, as shown below:

import cmath


def sqrt():
    try:
        num = int(input("Enter the number : "))
        if num >= 0:
            main(num)
        else:
            complex_num(num)
    except:
        print("OOPS..!!Something went wrong, try again")
        sqrt()
    return


def main(num):
    square_root = num ** (1 / 2)
    print("The square Root of ", num, " is ", square_root)
    return


def complex_num(num):
    ans = cmath.sqrt(num)
    print("The Square root if ", num, " is ", ans)
    return


sqrt()

answered Aug 9, 2017 at 10:06

with warnings:-  
import math  
def my():  
    print("hello world")  
my()

Without warnings:-  
import math 


def my():  
    print("hello world")  
my()

Here if you see the two lines space after import statement for second code snippet which will not give any warnings.
Again if you are writing two methods definition you have two give two lines as space between your code block.

answered Aug 9, 2017 at 11:24

All answers seem to be correct. To avoid doing this by hand, you can also use the autopep8 package (pip install autopep8). The result of calling autopep8 filename.py is the same:

import cmath


def sqrt():
    try:
        num = int(input("Enter the number : "))
        if num >= 0:
            main(num)
        else:
            complex(num)
    except:
        print("OOPS..!!Something went wrong, try again")
        sqrt()
    return


def main(num):
    squareRoot = num**(1/2)
    print("The square Root of ", num, " is ", squareRoot)
    return


def complex(num):
    ans = cmath.sqrt(num)
    print("The Square root if ", num, " is ", ans)
    return


sqrt()

PS: have a look at if __name__ == "__main__":

answered Mar 8, 2018 at 9:48

serv-incserv-inc

34.6k9 gold badges161 silver badges182 bronze badges

Источник

When to Use Two Blank Lines? PEP 8 Style Guide

Surround top-level function and class definitions with two blank lines.

Figure: The golden rule of when to use two blank lines in Python.

The following two rules will provide you a sufficient heuristic on when to use two blank lines:

Surround top-level function and class definitions with two blank lines.
Insert two blank lines after the import statements if the code that follows starts with a top-level function or class definition.

The second rule is a consequence of the first rule so it could be technically ommitted.

When to Use Single Blank Lines? PEP 8 Style Guide

The following four rules will provide you a sufficient heuristic on when to use a single blank line:

Use one or more extra single blank lines to separate groups of related functions.
Use a single blank line in functions to separate logical sections.
Use a single blank line to surround method definitions inside a class.
Do not use a single blank line between related Python one-liners.

Let’s have a look at some examples in code next!

Two Blank Lines Top Level Functions

#1.1 – Surround top-level function with two blank lines.

WRONG:

import x

def f():
    pass

f()

CORRECT:

import x


def f():
    pass


f()

One Blank Line Non-Top-Level Function

#1.2 – Surround non-top-level function with single blank lines.

WRONG:

import x


def f():


    def g():
        pass


    g()


f()

CORRECT:

import x


def f():

    def g():
        pass

    g()


f()

Two Blank Lines Top-Level Class Definition

#1.3 – Surround top-level class definitions with two blank lines.

WRONG:

print('hello')

class X:
  
    class Y:
        pass

    class Z:
        pass

print('world')

CORRECT:

print('hello')


class X:
  
    class Y:
        pass

    class Z:
        pass


print('world')

Note that the non-top-level class definitions Y and Z are not surrounded with two blank lines which is correct and in accordance with the rule.

Two Blank Lines Import Statements

While many online sources state that there should be two blank lines after the import statements before the code starts, this is not generally correct. PEP 8 only states that top-level function or class definitions should be surrounded by two blank lines!

PEP 8 doesn’t talk about import statements specifically in regards of insertion of two blank lines!

If the import block is followed by a function or class definition, you should insert two blank lines in accordance to this rule.
If the import block is followed by, say, a global variable definition, you shouldn’t insert two blank lines—one is enough!

Import Statements Followed by Two Blank Lines:

The following code snippet exemplifies the correct insertion of two blank lines after the import statement. But the blank lines are not there because of the import statement. They are there because of the top-level function definition of f.

# Correct
import x
import y
import z


def f():
    pass


f()

Import Statements NOT Followed by Two Blank Lines:

The following code snippet exemplifies the correct insertion of only one empty line after the import statement because we define a global variable MY_VAR that is neither a class nor a function definition and, thereby, shouldn’t be surrounded by two blank lines!

# Correct
import x
import y
import z

MY_VAR = 42

The logical implication is that the rule import statements should be followed by two blank lines is incorrect!

Next, we’ll explore some examples where only one single blank line can or should be inserted.

Single Blank Lines

#3 – Use one or more extra single blank lines to separate groups of related functions.

def f1():
    pass


def f2():
    pass


def f3():
    pass




def g1():
    pass


def g2():
    pass


def g3():
    pass

#4 – Use a single blank line in functions to separate logical sections.

def f1():
    print('first')
    print('logical')
    print('section')

    print('second')
    print('logical')
    print('section')


f1()

#5 – Use a single blank line to surround method definitions inside a class.

class X:

    def __init__(self):
        pass

    def x1():
        pass

    def x2():
        pass

    def x3():
        pass


x = X()

x.x1()
x.x2()
x.x3()

A common style error is to surround method definitions by two lines instead of one because people wrongly remember rule #1.

Here’s such a wrong example:

# WRONG
class X:


    def __init__(self):
        pass


    def x1():
        pass


    def x2():
        pass


    def x3():
        pass


x = X()

x.x1()
x.x2()
x.x3()

Too much whitespace!

Do not surround method definitions with two blank lines!

Blank Lines Around One-Liners

#6 – Do not use a single blank line between related Python one-liners.

For example, if you write the specification of three functions for later implementation, you can simply omit the blank lines around one-liner function definitions to avoid too much whitespace in the code.

Like so:

def f1(): pass
def f2(): pass
def f3(): pass

Expected 2 blank lines, found 0 (E302)

Python may raise an error or informational message:

expected 2 blank lines, found 0 (E302)
expected 2 blank lines, found 1 (E302)

To fix this error, surround the top-level function or class definitions with two blank lines instead of zero or one to adhere to the PEP 8 style guide.

No! Do NOT Do This:

def f1():
    pass
def f2():
    pass

Yes! Do This Instead:

def f1():
    pass


def f2():
    pass

Here are some quick references for further reading.

References:

https://stackoverflow.com/questions/2953250/python-pep8-blank-lines-convention
https://peps.python.org/pep-0008/#blank-lines
https://www.reddit.com/r/learnprogramming/comments/tnmhwe/when_to_use_blank_lines_in_python_in_order_to/
https://www.flake8rules.com/rules/E302.html

Programmer Humor

“Real programmers set the universal constants at the start such that the universe evolves to contain the disk with the data they want.” — xkcd

While working as a researcher in distributed systems, Dr. Christian Mayer found his love for teaching computer science students.

To help students reach higher levels of Python success, he founded the programming education website Finxter.com. He’s author of the popular programming book Python One-Liners (NoStarch 2020), coauthor of the Coffee Break Python series of self-published books, computer science enthusiast, freelancer, and owner of one of the top 10 largest Python blogs worldwide.

His passions are writing, reading, and coding. But his greatest passion is to serve aspiring coders through Finxter and help them to boost their skills. You can join his free email academy here.

Источник

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

В этой статье основное внимание уделяется упомянутым выше рекомендациям
по написанию правильного кода, представляющего более питонический способ
программирования. Это подборка руководств, ориентированных на
практическое использование, а дальнейшие рекомендации можно прочитать в
«Автостопом» по
Python{.amazon-link} и
« Руководстве по стилю
PEP8» .

Тим Питерс — американский разработчик Python — юмористически сочетает
принципы языка с дзеном Python. Эти правила включают основные цели и
стиль языка. Надеюсь, эти правила помогут вам сориентироваться как
разработчик.

Дзен Python

 Beautiful is better than ugly. 
 Explicit is better than implicit. 
 Simple is better than complex. 
 Complex is better than complicated. 
 Flat is better than nested. 
 Sparse is better than dense. 
 Readability counts. 
 Special cases aren't special enough to break the rules. 
 Although practicality beats purity. 
 Errors should never pass silently. 
 Unless explicitly silenced. 
 In the face of ambiguity, refuse the temptation to guess. 
 There should be one-- and preferably only one --obvious way to do it. 
 Although that way may not be obvious at first unless you're Dutch. 
 Now is better than never. 
 Although never is often better than right now. 
 If the implementation is hard to explain, it's a bad idea. 
 If the implementation is easy to explain, it may be a good idea. 
 Namespaces are one honking great idea -- let's do more of those! 
 --Tim Peters

Общие рекомендации по программированию

Следуя дзену Python, важна удобочитаемость кода. Чтобы обеспечить
правильно отформатированный код, в языке Python есть некоторые
рекомендации по программированию, изложенные в PEP8 — например,
согласованный отступ, определенная длина строки, запись только одного
оператора на строку и формулирование фрагментов кода скорее явным, чем
неявным способом. Ниже мы объясним эти правила шаг за шагом.

Отступ

Отступы необходимы для классов, функций (или методов), циклов, условий и
списков. Вы можете использовать табуляторы или пробелы, но вы не должны
комбинировать их оба в одном скрипте. Для Python 3 пробелы являются
предпочтительным методом отступа, а точнее, желательно четыре пробела.
Например, список рекомендуется определять одним из следующих двух
способов:

Написание списков

 # version 1 
 numbers = [ 
 1, 2, 3, 
 4, 5, 6 
 ] 
 
 # version 2 
 numbers = [ 
 1, 2, 3, 
 4, 5, 6 
 ]

Как указано в PEP8, закрывающая скобка может быть либо выровнена под
первым непробельным символом последней строки списка, как в «версии 1»,
либо под первым символом строки, которая начинает список как в «версии
2».

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

Плохой пример

 def draw_point(x, y): 
 """draws a point at position x,y""" 
 
 if (x > 0): 
 set_point(x, y) 
 return

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

Хороший пример

 def draw_point(x, y): 
 """draws a point at position x,y""" 
 
 if (x > 0): 
 set_point(x, y) 
 return

Одно заявление в строке

В приведенном выше примере следует еще одно важное правило написания
кода: используйте только один оператор в строке. Хотя язык Python
позволяет писать несколько операторов в каждой строке, разделенных
точкой с запятой, как показано ниже:

Плохо

 print ("Berlin"); print ("Cape Town") 
 
 if x == 1: print ("Amsterdam")

Вместо этого для большей ясности напишите такой код:

Хорошо

 print ("Berlin") 
 print ("Cape Town") 
 
 if x == 1: 
 print ("Amsterdam")

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

Плохая практика

 import sys, os

Вместо этого гораздо лучше импортировать по одному модулю на строку:

Хорошая практика

 import sys 
 import os

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

Импорт внешних модулей

 # use operating-system specific routines 
 import os 
 
 # use regular expressions routines 
 import re 
 
 # use SAX XML library/parser 
 from xml.sax import make_parser, handler 
 ...

Длина линии

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

Код с разрывом строки

 with open('/path/to/some/file/you/want/to/read') as file_1,  
 open('/path/to/some/file/being/written', 'w') as file_2: 
 file_2.write(file_1.read())

Явный и неявный код

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

В приведенном ниже примере функция calculation() скрывает два значения
x и y в одном параметре с именем args . Этот способ написания
также позволяет вызывающим абонентам при желании передавать функции
больше или меньше этих значений, но на первый взгляд это неочевидно.

Плохо

 def calculation(*args): 
 """calculation of the total""" 
 
 x, y = args 
 return (x+y) 
 
 print(calculation(3, 4))

Для большей ясности рекомендуется вместо этого написать так:

Хорошо

 def calculation(x,y): 
 """calculation of the total""" 
 
 total = x + y 
 return (total) 
 
 print(calculation(3, 4))

Соглашения об именах

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

Варианты именования стилей

 shoppingcart = [] # lowercase 
 shopping_cart = [] # lowercase with underscores 
 SHOPPINGCART = [] # uppercase 
 SHOPPING_CART = [] # uppercase with underscores 
 ShoppingCart = [] # capitalized words 
 shoppingCart = [] # mixed style

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

Имена идентификаторов должны быть совместимы с ASCII.
Модули должны иметь короткие имена в нижнем регистре.
Классы следуют соглашению о прописных словах
Исключения следуют соглашению о прописных словах и, как ожидается,
будут иметь Error если они относятся к ошибкам.
Константы пишутся прописными буквами

Для получения дополнительных сведений ознакомьтесь со стандартом PEP8.

Мы также должны отметить, что использование подхода «нижний регистр с
подчеркиванием» при именовании переменных в Python считается более
«питоническим», хотя любой подход разрешен.

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

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

Как упоминалось выше, рекомендации описаны в PEP8. Следовательно, язык
Python содержит соответствующий инструмент командной строки, который
поможет вам проверить ваш код на соответствие рекомендациям.
Первоначально известная как pep8 , эта программа проверки кода была
переименована в pycodestyle в 2016
году. Она поддерживается Управлением контроля качества кода Python и
принадлежит к ряду инструментов, таких как анализаторы исходного кода
pylint и
pyflakes , средство проверки
сложности mccabe, а также
docstring. шашечный пидокстиль .

pycodestyle анализирует ваш код Python и сообщает о нарушениях,
касающихся ошибок отступов, ненужных пустых строк и использования
табуляторов вместо пробелов. В следующем примере содержится образец
выходных данных с некоторыми типичными ошибками и предупреждениями:

 $ pycodestyle --first stack.py 
 stack.py:3:1: E265 block comment should start with '# ' 
 stack.py:12:1: E302 expected 2 blank lines, found 1 
 stack.py:13:1: W191 indentation contains tabs

В Debian GNU / Linux инструмент доступен в виде пакетов
python-pycodestyle (для Python 2.x) и python3-pycodestyle (для
Python 3.x). Оба они имеют ряд полезных параметров, например:

--first : показать первое появление каждой ошибки (как показано
выше). В выходных данных отображается файл, в котором была
обнаружена ошибка, а также номер строки и столбец.
--show-source : показывать исходный код для каждой ошибки

 $ pycodestyle --show-source stack.py 
 stack.py:3:1: E265 block comment should start with '# ' 
 #o 
 ^ 
 stack.py:12:1: E302 expected 2 blank lines, found 1 
 class Stack: 
 ^ 
 stack.py:13:1: W191 indentation contains tabs 
 def __init__(self): 
 ^ 
 ...

--statistics : подсчет ошибок и предупреждений. В следующем
примере pycodestyle обнаружил две ошибки — E265 и E302, а также 30
предупреждений (W191).

 $ pycodestyle --statistics stack.py 
 ... 
 1 E265 block comment should start with '# ' 
 1 E302 expected 2 blank lines, found 1 
 30 W191 indentation contains tabs

Этот же инструмент также доступен в Интернете
. Просто скопируйте и вставьте свой код в инструмент и посмотрите
результат проверки.

{.ezlazyload
.img-responsive}

Заключение

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

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

Автор благодарит Золеку Хатитонгве за поддержку при подготовке статьи.

Источник

Время прочтения
7 мин

Просмотры 125K

Автор: Анатолий Соловей, developer

Язык программирования Python очень востребован на современном рынке, он развивается изо дня в день, и вокруг него сложилось активное сообщество. Во избежание конфликтов между разработчиками-питонистами, создатели языка написали соглашение PEP 8, описывающее правила оформления кода, однако даже там отмечено, что:

Many projects have their own coding style guidelines. In the event of any conflicts, such project-specific guides take precedence for that project.

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

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

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

На помощь в этом случае приходят линтеры — инструменты, контролирующие оформление кода в проекте. Именно они помогают поддерживать его чистоту и, в нашем случае, предотвращать создание коммитов, которые могут содержать ошибки. Я для контроля качества использую Flake8 и сейчас постараюсь объяснить, почему выбрал именно его, и расскажу, как его настроить, чтобы получить максимальный результат. Заинтересовались? Добро пожаловать под кат.

Flake8: Your Tool For Style Guide Enforcement

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

Flake8 умеет работать не только с PEP 8, но и с другими правилами, к тому же поддерживает кастомные плагины, поэтому в дальнейшем в этой статье я буду отталкиваться от правил из Google Python Style Guide.

Почему Flake8?

Flake8: pep8 + pyflakes + more

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

Легкость установки и конфигурации

Чтобы проверить, отвечает ли код в вашем проекте основным требованиям PEP 8, достаточно установить Flake:

$ pip install flake8

и запустить его — просто ввести в командной строке:

$ flake8 my_project

после чего вы получите список с именами файлов и номерами строк, где были допущены ошибки, и подробное описание самих ошибок:

$ flake8 my_project
myfile.py:1: 'sys' imported but unused
myfile.py:4:1: E302 expected 2 blank lines, found 1

Великолепно, не правда ли? Но и это не всё. Если вы не любитель работать с консолью, то вы можете настроить интеграцию Flake8 с IDE или редактором, который вы предпочитаете использовать.

Интеграция Flake8 с редакторами и IDE

Интеграция с PyCharm
Так же актуально и для любой другой IDE от JetBrains.
Интеграция проводится всего за пару несложных шагов.

Откройте настройки External Tools в File → Settings → Tools и нажмите на “+”, затем заполните поля по этому шаблону:

После этого нажмите на Output Filters, а затем на “+”, чтобы добавить новое правило для вывода сообщений от флейка:

Здесь мы говорим PyCharm, что хотим, чтобы в выводе строки с ошибками были кликабельными и открывали в редакторе файл и место с ошибкой

Все. Интеграция Flake8 с PyCharm закончена. Чтобы вызвать флейк и проверить свой код, кликаем правой кнопкой мыши на файл/директорию, которую мы хотим проверить, и в контекстном меню выбираем External Tools → Flake8.

В выводе PyCharm появится кликабельный список нарушений в выбранном файле/директории:

Интеграция с Atom
Чтобы установить инструмент Flake8 для Atom, используйте Atom package manager в Settings и найдите там linter-flake8:

Или вызовите


apm install flake8

из командной строки.

Затем перейдите в linter-flake8 settings и укажите путь к директории, где установлен flake8:

У linter-flake8 есть собственный ReadMe по настройке, с которым при желании вы можете ознакомиться на странице самого linter-flake8 в Atom.

Наличие Version Control Hooks

Именно это я считаю главным достоинством Flake8, которое выделяет его среди других линтеров. В отличии от большинства подобных инструментов, где для настройки VCS-хуков используются целые отдельные библиотеки и модули (как, например, в Pylint), настройка хуков в флейке проводится буквально в две строчки.

На момент написания этой статьи, Flake8 умеет использовать pre-commit-хуки для Git и Mercurial. Эти хуки позволяют, например, не допускать создания коммита при нарушении каких-либо правил оформления.

Установить хук для Git:

$ flake8 --install-hook git

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

$ git config --bool flake8.strict true

Я продемонстрирую, как Git hook работает на проекте, который я использовал для примера интеграции Flake8 с PyCharm. В модуле flake8tutorial.py мы видим очевидные ошибки: импортированные и неиспользованные модули, остсутствие докстринга и пустой строки в конце файла.

Первым делом проинициализируем в этом проекте git-0репозиторий, установим flake8 хук и скажем нашему git, что он должен прогонять флейк перед коммитами:

Затем попробуем провести первый коммит:

Как видите, flake8 был вызван перед коммитом и не позволил нам закоммитить невалидные изменения.

Теперь фиксим ошибки, отмеченные флейком, и пытаемся закоммитить валидный код:

Коммит успешно создан. Отлично!

Настройка Flake8 для Mercurial практически идентична. Для начала нужно установить Flake8 Mercurial Hook:

$ flake8 --install-hook mercurial

И настроить сам Mercurial:

$ hg config flake8.strict true

Вот и все, хук для Меrcurial установлен, настроен и готов к использованию!

Подробнее о конфигурации Flake8

Базовая конфигурация

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

flake8 --select E123

(в этом примере опцией select мы говорим, чтобы Flake сообщал о нарушениях только правила E123 (это код правила “closing bracket does not match indentation of opening bracket’s line”)).

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

На мой взгляд, куда предпочтительнее настраивать Flake с помощью конфигурационных файлов, вы можете хранить настройки в одном из файлов setup.cfg, tox.ini или.flake8. Для ясности я предпочитаю использовать последний вариант.

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

[flake8]
ignore = D203
exclude = .git,__pycache__,docs/source/conf.py,old,build,dist

В этом файле мы сообщаем Flake, что он не должен оповещать нас о нарушениях правила D203 (“1 blank line required before class docstring”), а также не должен проверять файлы .git, __pycache__, docs/source/conf.py и директории old, build, dist.

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

[flake8]
# it's not a bug that we aren't using all of hacking
ignore =
    # F812: list comprehension redefines ...
    F812,
    # H101: Use TODO(NAME)
    H101,
    # H202: assertRaises Exception too broad
    H202,
    # H233: Python 3.x incompatible use of print operator
    H233,
    # H301: one import per line
    H301,
    # H306: imports not in alphabetical order (time, os)
    H306,
    # H401: docstring should not start with a space
    H401,
    # H403: multi line docstrings should end on a new line
    H403,
    # H404: multi line docstring should start without a leading new line
    H404,
    # H405: multi line docstring summary not separated with an empty line
    H405,
    # H501: Do not use self.__dict__ for string formatting
    H501

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

import sys # noqa

Модули, расширяющие функциональность

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

flake8-import-order

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

Этот плагин расширяет список предупреждений Flake, добавляя туда три новых:

I100: Your import statements are in the wrong order.
I101: The names in your from import are in the wrong order.
I201: Missing newline between sections or imports.

Установка:

pip install flake8-import-order

Конфигурация:

[flake8]
application-import-names = my_project, tests # Указываем флейку директории, в которых хранятся локальные пакеты.

import-order-style = google # Указываем флейку на то, в каком порядке должны идти импорты. Как я уже говорил выше, я предпочитаю использовать Google Style Guide.

Более подробно о настройке flake8-import-order можно прочитать на странице библиотеки на Github.

flake8-docstrings

Плагин, добавляющий поддержку функционала из pydocstyle — проверку докстрингов на соответствие конвенциям Питона.

Установка:

pip install flake8_docstrings

Список добавляемых этой библиотекой правил можно найти в документации pydocstyle.

Конфигурация:

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

[flake8]
ignore = D101 # Игнорировать docstrings предупреждение “Missing docstring in public class”

Страница библиотеки на Github тут.

flake8-builtins

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

Установка:

pip install flake8-builtins

Конфигурация:

Как и в случае с flake8-docstrings, у плагина нет дополнительных настроек, но добавленные им правила можно, например, внести в исключения флейка:

[flake8]
ignore = B001 # Игнорировать builtins предупреждение “<some_builtin> is a python builtin and is being shadowed, consider renaming the variable”

Более подробную информацию об этом плагине можно найти на странице этого плагина на Github.

flake8-quotes

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

Установка:

pip install flake8-quotes

Конфигурация:

[flake8]
inline-quotes = " # Указываем, какой тип кавычек должен использоваться в вашем проекте

Более подробную информацию об этом плагине можно найти на странице этого плагина на Github.

Послесловие

Хотя настройки, описанные выше, в 97,5 % случаев смогут предотвратить появление некачественного кода в репозитории, он так или иначе может оказаться запушенным (например, если деву было лень вводить две строчки для настройки pre-commit hook). Поэтому я настоятельно рекомендую добавить вызов Flake8 на этапе билда пул-реквестов в используемой вами системе continuous integration, чтобы предотвратить мердж невалидных пул-реквестов и попадание ошибок в мастер.

Надеюсь, эта статья была вам полезна и позволит в дальнейшем максимально гибко и качественно настраивать рабочий процесс и стайлгайды в ваших Python-проектах. Всех благ.

Список источников:

Документация Flake8
Useful Python Modules: Flake8
Google Python Style Guide

Источник

When to Use Two Blank Lines? PEP 8 Style Guide

When to Use Single Blank Lines? PEP 8 Style Guide

Two Blank Lines Top Level Functions

One Blank Line Non-Top-Level Function

Two Blank Lines Top-Level Class Definition

Two Blank Lines Import Statements

Single Blank Lines

Blank Lines Around One-Liners

Expected 2 blank lines, found 0 (E302)

No! Do NOT Do This:

Yes! Do This Instead:

Programmer Humor

Общие рекомендации по программированию

Отступ

Одно заявление в строке

Длина линии

Явный и неявный код

Соглашения об именах

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

Заключение

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

Flake8: Your Tool For Style Guide Enforcement

Почему Flake8?

Flake8: pep8 + pyflakes + more

Легкость установки и конфигурации

Интеграция Flake8 с редакторами и IDE

Наличие Version Control Hooks

Подробнее о конфигурации Flake8

Базовая конфигурация

Модули, расширяющие функциональность

Послесловие

Читайте также: