В первой части статьи, опубликованной на pythonist.ru (с которой мы уже знакомили вас ранее), разбиралось, почему качество кода имеет такое большое значение, какой код можно считать качественным и на какие стандарты можно ориентироваться.
Представляем вам вторую часть статьи, в которой подробнее рассматривается, на что способны различные линтеры и как выглядит результат их работы.
Для сравнения пропустим одинаковый код через несколько линтеров с дефолтными настройками.
Проверять будем следующий код. В нем есть целый ряд логических и стилистических ошибок:
"""
code_with_lint.py
Example Code with lots of lint!
"""
import io
from math import *
from time import time
some_global_var = 'GLOBAL VAR NAMES SHOULD BE IN ALL_CAPS_WITH_UNDERSCOES'
def multiply(x, y):
"""
This returns the result of a multiplation of the inputs
"""
some_global_var = 'this is actually a local variable...'
result = x* y
return result
if result == 777:
print("jackpot!")
def is_sum_lucky(x, y):
"""This returns a string describing whether or not the sum of input is lucky
This function first makes sure the inputs are valid and then calculates the
sum. Then, it will determine a message to return based on whether or not
that sum should be considered "lucky"
"""
if x != None:
if y is not None:
result = x+y;
if result == 7:
return 'a lucky number!'
else:
return( 'an unlucky number!')
return ('just a normal number')
class SomeClass:
def __init__(self, some_arg, some_other_arg, verbose = False):
self.some_other_arg = some_other_arg
self.some_arg = some_arg
list_comprehension = [((100/value)*pi) for value in some_arg if value != 0]
time = time()
from datetime import datetime
date_and_time = datetime.now()
return
В таблице ниже мы разместили список используемых линтеров и время, которое им понадобилось на анализ этого файла. Следует отметить, что все эти инструменты служат разным целям, поэтому сравнивать, возможно, не совсем правильно. PyFlakes, например, не выявляет стилистические ошибки, как это делает Pylint.
| ЛИНТЕР | КОМАНДА | ВРЕМЯ |
|---|---|---|
| Pylint | pylint code_with_lint.py | 1,16 с |
| PyFlakes | pyflakes code_with_lint.py | 0,15 с |
| pycodestyle | pycodestyle code_with_lint.py | 0,14 с |
| pydocstyle | pydocstyle code_with_lint.py | 0,21 с |
Теперь давайте посмотрим на результаты.
Pylint
Pylint это один из самых старых линтеров (работает с 2006 года), но при этом он хорошо поддерживается. Можно сказать, что этот инструмент проверен временем. Контрибьюторы уже давно пофиксили все основные баги, а главный функционал хорошо отшлифовали.
Самые распространенные жалобы на Pylint — медленная работа, излишняя многословность по умолчанию и необходимость долго копаться в настройках, чтобы сделать все по своему вкусу. Если отбросить скорость работы, все остальные пункты — палка о двух концах. Многословность объясняется скрупулезностью. Большое количество настроек позволяет подогнать под свои нужды очень многие вещи.
Итак, вот результат запуска Pylint для приведенного выше кода:
No config file found, using default configuration * Module code_with_lint W: 23, 0: Unnecessary semicolon (unnecessary-semicolon) C: 27, 0: Unnecessary parens after 'return' keyword (superfluous-parens) C: 27, 0: No space allowed after bracket return( 'an unlucky number!') ^ (bad-whitespace) C: 29, 0: Unnecessary parens after 'return' keyword (superfluous-parens) C: 33, 0: Exactly one space required after comma def init(self, some_arg, some_other_arg, verbose = False): ^ (bad-whitespace) C: 33, 0: No space allowed around keyword argument assignment def init(self, some_arg, some_other_arg, verbose = False): ^ (bad-whitespace) C: 34, 0: Exactly one space required around assignment self.some_other_arg = some_other_arg ^ (bad-whitespace) C: 35, 0: Exactly one space required around assignment self.some_arg = some_arg ^ (bad-whitespace) C: 40, 0: Final newline missing (missing-final-newline) W: 6, 0: Redefining built-in 'pow' (redefined-builtin) W: 6, 0: Wildcard import math (wildcard-import) C: 11, 0: Constant name "some_global_var" doesn't conform to UPPER_CASE naming style (invalid-name) C: 13, 0: Argument name "x" doesn't conform to snake_case naming style (invalid-name) C: 13, 0: Argument name "y" doesn't conform to snake_case naming style (invalid-name) C: 13, 0: Missing function docstring (missing-docstring) W: 14, 4: Redefining name 'some_global_var' from outer scope (line 11) (redefined-outer-name) W: 17, 4: Unreachable code (unreachable) W: 14, 4: Unused variable 'some_global_var' (unused-variable) … R: 24,12: Unnecessary "else" after "return" (no-else-return) R: 20, 0: Either all return statements in a function should return an expression, or none of them should. (inconsistent-return-statements) C: 31, 0: Missing class docstring (missing-docstring) W: 37, 8: Redefining name 'time' from outer scope (line 9) (redefined-outer-name) E: 37,15: Using variable 'time' before assignment (used-before-assignment) W: 33,50: Unused argument 'verbose' (unused-argument) W: 36, 8: Unused variable 'list_comprehension' (unused-variable) W: 39, 8: Unused variable 'date_and_time' (unused-variable) R: 31, 0: Too few public methods (0/2) (too-few-public-methods) W: 5, 0: Unused import io (unused-import) W: 6, 0: Unused import acos from wildcard import (unused-wildcard-import) … W: 9, 0: Unused time imported from time (unused-import)
Имейте в виду, что похожие строки в тексте заменены многоточиями. Разобраться довольно сложно, но в этом коде много ошибок.
Обратите внимание, что Pylint добавляет к каждой проблемной области префикс R, C, W, E или F, что означает:
- [R]efactor — нужен рефакторинг, поскольку показатель «good practice» не на должном уровне.
- [C]onvention — нарушение соглашения о стандарте кода
- [W]arning — предупреждение о стилистических проблемах или минорных программных проблемах
- [E]rror — существенные проблемы в программе (скорее всего баг)
- [F]atal — ошибки, мешающие дальнейшей работе.
Приведенный список — из пользовательского руководства Pylint.
PyFlakes
Pyflakes «торжественно клянется никогда не жаловаться на стиль и очень усердно стараться не допускать ложнопозитивных срабатываний». То есть Pyflakes не сообщит вам о пропущенных docstrings или о том, что имена аргументов не соответствуют стилю нейминга. Он фокусируется на логических проблемах в коде и потенциальных ошибках.
Преимущество этого инструмента в скорости. PyFlakes обработал файл лишь за небольшую долю времени, которое потребовалось Pylint.
Вывод после запуска Pyflakes для приведенного выше кода:
code_with_lint.py:5: 'io' imported but unused code_with_lint.py:6: 'from math import *' used; unable to detect undefined names code_with_lint.py:14: local variable 'some_global_var' is assigned to but never used code_with_lint.py:36: 'pi' may be undefined, or defined from star imports: math code_with_lint.py:36: local variable 'list_comprehension' is assigned to but never used code_with_lint.py:37: local variable 'time' (defined in enclosing scope on line 9) referenced before assignment code_with_lint.py:37: local variable 'time' is assigned to but never used code_with_lint.py:39: local variable 'date_and_time' is assigned to but never used
Недостаток Pyflakes в том, что в результатах его работы немного труднее разобраться. Различные проблемы и ошибки никак не помечены и не упорядочены. Но будет ли это для вас проблемой, зависит от вашего использования этого инструмента.
pycodestyle (прежде — pep8)
Этот инструмент проверяет код на соответствие некоторым соглашениям из PEP 8. Нейминг не проверяется, так же как и docstrings. Ошибки и предупреждения, выдаваемые этим инструментом, можно посмотреть в таблице.
Результат использования pycodestyle для приведенного выше кода:
code_with_lint.py:13:1: E302 expected 2 blank lines, found 1
code_with_lint.py:15:15: E225 missing whitespace around operator
code_with_lint.py:20:1: E302 expected 2 blank lines, found 1
code_with_lint.py:21:10: E711 comparison to None should be 'if cond is not None:'
code_with_lint.py:23:25: E703 statement ends with a semicolon
code_with_lint.py:27:24: E201 whitespace after '('
code_with_lint.py:31:1: E302 expected 2 blank lines, found 1
code_with_lint.py:33:58: E251 unexpected spaces around keyword / parameter equals
code_with_lint.py:33:60: E251 unexpected spaces around keyword / parameter equals
code_with_lint.py:34:28: E221 multiple spaces before operator
code_with_lint.py:34:31: E222 multiple spaces after operator
code_with_lint.py:35:22: E221 multiple spaces before operator
code_with_lint.py:35:31: E222 multiple spaces after operator
code_with_lint.py:36:80: E501 line too long (83 > 79 characters)
code_with_lint.py:40:15: W292 no newline at end of file
Что здесь хорошо, это то, что ошибки имеют метки категорий. Вы можете игнорировать определенные ошибки, если соответствие какому-то конкретному соглашению вас не заботит.
pydocstyle (прежде — pep257)
Этот инструмент очень похож на предыдущий, pycodestyle, за исключением того, что проверяет код не на соответствие PEP 8, а на соответствие PEP 257.
Результат запуска для приведенного выше кода:
code_with_lint.py:1 at module level:
D200: One-line docstring should fit on one line with quotes (found 3)
code_with_lint.py:1 at module level:
D400: First line should end with a period (not '!')
code_with_lint.py:13 in public function `multiply`:
D103: Missing docstring in public function
code_with_lint.py:20 in public function `is_sum_lucky`:
D103: Missing docstring in public function
code_with_lint.py:31 in public class `SomeClass`:
D101: Missing docstring in public class
code_with_lint.py:33 in public method `__init__`:
D107: Missing docstring in __init__
Как и pycodestyle, pydocstyle помечает и разбивает по категориям найденные ошибки. Этот список не конфликтует ни с чем из pycodestyle, поскольку все ошибки имеют приставку D (означающую docstring). Список ошибок можно посмотреть здесь.
Код без ошибок
Если учесть предупреждения и исправить ошибки, найденные линтерами, вы получите примерно такой код:
"""Example Code with less lint."""
from math import pi
from time import time
from datetime import datetime
SOME_GLOBAL_VAR = 'GLOBAL VAR NAMES SHOULD BE IN ALL_CAPS_WITH_UNDERSCOES'
def multiply(first_value, second_value):
"""Return the result of a multiplation of the inputs."""
result = first_value * second_value
if result == 777:
print("jackpot!")
return result
def is_sum_lucky(first_value, second_value):
"""
Return a string describing whether or not the sum of input is lucky.
This function first makes sure the inputs are valid and then calculates the
sum. Then, it will determine a message to return based on whether or not
that sum should be considered "lucky".
"""
if first_value is not None and second_value is not None:
result = first_value + second_value
if result == 7:
message = 'a lucky number!'
else:
message = 'an unlucky number!'
else:
message = 'an unknown number! Could not calculate sum...'
return message
class SomeClass:
"""Is a class docstring."""
def __init__(self, some_arg, some_other_arg):
"""Initialize an instance of SomeClass."""
self.some_other_arg = some_other_arg
self.some_arg = some_arg
list_comprehension = [
((100/value)*pi)
for value in some_arg
if value != 0
]
current_time = time()
date_and_time = datetime.now()
print(f'created SomeClass instance at unix time: {current_time}')
print(f'datetime: {date_and_time}')
print(f'some calculated values: {list_comprehension}')
def some_public_method(self):
"""Is a method docstring."""
pass
def some_other_public_method(self):
"""Is a method docstring."""
pass
Согласно «мнению» приведенных выше линтеров, этот код больше не имеет «ворсинок». И хотя логика сама по себе бессмысленная, вы можете заметить, что, как минимум, этот код отличается единообразием.
В рассмотренном случае мы запускали линтеры на уже написанном коде. Но это не единственный способ проверки качества кода.
Когда можно проверять качество кода?
Вы можете проверять качество своего кода:
- по мере написания,
- перед отправкой,
- при запуске тестов.
Проверять код при помощи линтеров лучше почаще. Если в многочисленной команде или на большом проекте такие проверки не автоматизированы, там будет легко упустить из виду ухудшение качества кода. Оно происходит постепенно, конечно. Какая-нибудь плохо прописанная логика, какой-то код, формат которого не соответствует соседнему коду. Со временем все эти шероховатости накапливаются, и в конечном итоге у вас на руках может оказаться трудночитаемый, трудноисправляемый и гарантирующий головную боль при поддержке код с кучей багов.
Чтобы этого избежать, проверяйте качество кода почаще!
Проверка кода по мере его написания
Вы можете использовать линтеры по мере написания кода, но для этого может понадобиться дополнительно настроить вашу среду разработки. Чаще всего вам нужно будет найти подходящий плагин для вашей IDE или редактора. Но большинство IDE имеют и встроенные линтеры.
По ссылкам вы сможете найти полезную информацию по этой теме для разных редакторов:
Проверка кода перед его отправкой
Если вы используете Git, можно настроить Git hooks для запуска линтеров перед коммитом. Другие системы контроля версий имеют схожие методы для запуска скриптов в привязке к определенным действиям в системе. При помощи этих методов можно блокировать любой новый код, не соответствующий стандартам качества.
Это может показаться слишком радикальным подходом, но прогон каждого кусочка кода через линтеры — важный шаг на пути к обеспечению стабильно высокого качества. Автоматизация этих проверок — лучший способ избежать шероховатостей в коде.
При запуске тестов
Вы можете вставить линтеры в любую систему, которую используете для непрерывной интеграции. Линтеры при этом могут быть настроены таким образом, чтобы сборка в принципе не была возможна, если код не соответствует стандартам.
Опять же, это может показаться слишком радикальным решением, особенно если в уже существующем коде есть много ошибок, вылавливаемых линтерами. Но эту проблему можно обойти. В некоторых системах непрерывной интеграции можно выбрать опцию, при которой сборка проваливается только если новый код увеличивает число ошибок, найденных линтером. Таким образом вы сможете улучшать качество кода, не переписывая заново всю кодовую базу.
Заключение
Высококачественный код делает то, что он должен делать, не ломаясь при этом. Его легко читать, поддерживать и расширять. Он функционирует без проблем, в нем нет дефектов, а еще он написан так, чтобы следующему программисту было легко с ни м работать.
Естественно, каждый хочет, чтобы его код отличался высоким качеством. К счастью, есть методы и инструменты, позволяющие повысить качество кода.
Благодаря руководствам по стилю ваш код может стать единообразным. PEP8 — отличная отправная точка, если речь идет о Python. Линтеры помогут вам обнаружить проблемные места и стилевые несоответствия. Использовать эти инструменты можно на любой стадии процесса разработки; их можно даже автоматизировать, чтобы код с «пухом» не прошел слишком далеко.
Использование линтеров позволяет избежать ненужных дискуссий о стиле в ходе код-ревью. Некоторым людям морально легче получить объективный фидбэк от инструментов, а не от товарищей по команде. Кроме того, некоторые ревьюеры могут просто не хотеть «придираться» к стилю проверяемого кода. Линтеры не озабочены всеми этими политесами и экономией времени: они жалуются на любое несоответствие.
Кроме того, все линтеры, упомянутые в этой статье, имеют различные опции для ввода в командной строке и настройки, позволяющие подогнать инструмент под свои нужды. Важно понимать, что вы можете быть настолько строги или снисходительны, насколько захотите.
Улучшение качества кода это процесс. Вы можете предпринимать некоторые шаги в этом направлении и не выбрасывая весь несоответствующий стандарту код. Осведомленность — прекрасный первый шаг. Чтобы его сделать, нужно только осознать, насколько важно поддерживать высокое качество кода.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]