четверг, 31 марта 2011 г.

Python: PEP-8 или не PEP-8

Пост - не технический, кому не интересно - можете дальше не читать...

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

Итак, стандарт это в большинстве случаев хорошо, так как вносит порядок во что бы то ни было. Например, стандарт USB 2.0 - просто отличнейший стандарт, представьте себе, если бы флешки были не USB, а каждая имела бы свой выход :)... Ужас, да, были бы у нас USB-порты как card-reader'ы - 62 в 1..

Реально 62 в 1

Другое дело PEP-8. Тут все по другому, ведь программа не изменит своего поведения, если мы будем делать отступ не в 4 пробела, а 2 (хорошо, что большинство все-таки делает 4), или будем ставить пробел перед закрывающейся скобкой, или не будем и т.д.. 

Итак, каждый программист волен редактировать свой код как ему заблагорассудится. Мне, например, нравится стиль, предложенный в PEP-8, а многим вот не нравится. Но что же имеем, комманда работает над кодом и каждый пишет себе как хочет. Ладно, если это разные Python-модули, а если несколько человек вносят правки в один и тот же модуль, так читать такой код уже не просто неудобно, а местами даже довольно трудно.

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


Навеяно опытом поддержки и развития существующего Python-кода

P.S. 
А ще PEP-8 - это новый сайт, который освещает жизнь русскоязычного сообщества Python-программистов :)

8 комментариев:

  1. В pep8 напрягает ограничение на длину строк в 80-т символов, зачастую ухудшающее читаемость.

    Во всем остальном, отличный стандарт, которому не сложно следовать.

    ОтветитьУдалить
  2. Насчет 80 символов в строке - это как 140 символов в СМС-ке... ну, так сложилось. Вот тут - http://www.javatalks.ru/sutra60886.php народ нарыл истоки этого явления - перфокарты IBM 1928 года...

    Шутки-шутки, а пока есть те, кто сидит за маленькими мониторами, 80 символов - самая что не на есть классная фича стандарта.

    ОтветитьУдалить
  3. 2Rostislav: Для владельцев таких вот маленьких мониторов придумали перенос строк в редакторах.

    Если смотреть на вещи реально, то 95-100 символов - это как раз.

    ОтветитьУдалить
  4. А что плохого в 2х пробелах вместо 4х?

    ОтветитьУдалить
  5. can3p, если сместить ограничение с 80-ти символов на 100, то ваша фраза будет звучать так:

    > Если смотреть на вещи реально, то 115-120 символов - это как раз.

    У меня на эту тему долгий спор... ИМХО, 80 символов это та длина строки, когда стоит начинать искать способ перенести. Но нет ничего страшного, если всё-таки строка получится чуть больше.

    ОтветитьУдалить
  6. @can3p: искренне желаю вам не столкнуться вам с чтением кода с переносами строк, тут уже любое форматирование отдыхает

    @kodx: для меня очень нечитабельно, весь код сливается и выглядит почти что вертикально.

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

    ОтветитьУдалить
  8. Дайте и мне вставить 5 копеек. Очень не любил это ограничение в 79 (внимание, никак не 80) символов - пока не пришлось ему следовать в директивном порядке. Теперь считаю ровно наоборот.
    Если у вас широкий экран - поместите в нем 2, 3, 5 колонок с кодом. Это гораздо удобней, чем длинные строки.
    Когда открываю файл, у которого строки длиннее стандарта - читать его очень неудобно.

    ОтветитьУдалить

В этом гаджете обнаружена ошибка