Многие библиотеки Python имеют относительно низкое качество кода?
https://stackoverflow.com/questions/602096
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Редактировать: С тех пор, как был задан этот вопрос, в стандартных научных библиотеках Python (которые и были целевой областью) произошло множество улучшений.Например, проект numpy приложил большие усилия для улучшения строк документации.До сих пор можно спорить, можно ли было бы с самого начала постоянно решать эти проблемы.
У меня есть несколько еретический вопрос:Почему так много библиотек Python имеют беспорядочный код и не следуют стандартным рекомендациям?Или вы думаете, что это наблюдение абсолютно не соответствует действительности?Как ситуация по сравнению с другими языками?Мне интересно ваше мнение по этому поводу.
Некоторые причины, по которым у меня сложилось впечатление, что качество отсутствует:
Строки документации часто полностью отсутствуют или неполны, даже для общедоступного API.Больно, когда метод требует
*argsи**kwargsно не документирует, какие значения могут быть заданы.Плохие методы кодирования Python, такие как добавление новых атрибутов за пределами
__init__.Подобные вещи затрудняют чтение (или поддержку) кода.Вряд ли какие-либо библиотеки следуют соглашениям о кодировании PEP8.Иногда соглашения даже не согласованы в одном файле.
Общий дизайн беспорядочный, без четкого API.Кажется, что рефакторинга сделано недостаточно.
Плохое покрытие юнит-тестами.
Не поймите меня неправильно, Я очень люблю Python и его экосистему..И хотя я боролся с этими библиотеками они обычно выполняют свою работу, и я благодарен за это.Но я также думаю, что в конечном итоге из-за этих проблем тратится масса времени разработчиков.Может быть, это потому, что Python дает вам столько свободы, что написать плохой код очень легко..
Решение
Что касается документации, это не только Python.Если и есть один-единственный фактор, который препятствует более широкому внедрению OSS, так это, ИМХО, поистине ужасный уровень документации большинства проектов OSS.Это начинается на уровне кода и распространяется на пользовательскую документацию.Могу я просто сказать всем, кто работает над OSS:
а) Прокомментируйте свой код!Самодокументируемого кода не существует!
б) Потратьте не менее 25 % бюджета проекта на документацию для конечного пользователя.
И я смутно понимаю, о чем говорю: у меня есть пара собственных проектов OSS, я участвовал в нескольких других и использую почти исключительно OSS.А вчера я потратил более 4 часов, пытаясь создать крупный проект OSS (без имен, без пакетных упражнений), но потерпел неудачу из-за дрянной, противоречивой документации.
Другие советы
Вместо этого каждый из авторов, кажется, следует своему собственному славному соглашению.А иногда соглашения даже не соответствуют одному и тому же файлу библиотеки.
Добро пожаловать в чудесный код реального мира!
FWIW Код Python, который я встречал, не лучше и не хуже кода на любом другом языке.
(Ну, очевидно, лучше, чем средний PHP-проект, но это не совсем справедливо.)
Первое, что вам нужно осознать, это то, что Python не возник в полностью сформированном виде из головы Гвидо где-то около версии 2.x.Оно выросло за последние двадцать лет.
Фактически, некоторые из упомянутых вами вещей (например, unittest и PEP-8) даже не существовали, когда некоторые стандартные библиотеки были впервые написаны.
Вы, вероятно, заметите, что чем старше библиотека, на которую вы смотрите, тем больше вероятность того, что она будет отличаться от текущих «лучших практик» — часто потому, что они предшествовали широкому распространению этих практик.Более поздние библиотеки с большей вероятностью будут соответствовать нынешней практике.
Кроме того, иногда для этого есть веская причина. нет приведя их в актуальное состояние.Представьте, что у вас есть несколько десятков тысяч строк кода, написанных для текущих библиотек Python.Теперь сопровождающий одной из этих библиотек решает изменить библиотеки, чтобы имена классов и функций соответствовали PEP-8.Теперь всем, у кого есть работающий код, приходится пересматривать огромное количество его, чтобы переименование не сломало ситуацию.
Это не значит, что в библиотеках Python нет вещей, которые можно улучшить — они есть!Но всегда есть компромисс между совершенством и выполнением задач.Это одна из причин, по которой говорят: «Практичность важнее чистоты».
Это связано с тем, что Python не поддерживается корпоративным миром, таким как Java или .Net.
Если я хочу, чтобы Sun продвигала мою библиотеку Java, я буду следовать их рекомендациям.В случае с Python это не так.Я пишу свой код, люди находят его лучше, и он должен развиваться сам по себе.
Кроме того, большинство разработчиков Python работают на C++, C, Java, .Net и т. д.И они начинают писать производственный код прямо с первого дня.Благодаря простоте Python.И порочный круг продолжается.
Даже мне потребовался месяц, чтобы перейти на PEP8 и провести рефакторинг своего кода.
PEP 8 со временем изменился.Некоторые модули следуют старым рекомендациям.Вы можете видеть это на PIL, который использует такие модули, как «Image», где модуль содержит один основной класс вместо рекомендуемого нижнего регистра для имен модулей, а также в расширениях C, которые используют префикс «c», а не более современный « _" префикс.
Некоторые библиотеки разработаны людьми, на которых сильно влияют традиции других областей, таких как Java и C++.Эти люди чаще используют CamelCase вместо рекомендованного PEP 8 нижнего регистра_с_подчеркиванием.
Ответы здесь не были бы полными без ссылки на Закон Осетра:«Девяносто процентов всего — дерьмо».
Девяносто процентов [библиотек Python] — мусор, но девяносто процентов всего — мусор.
-- Закон об осетровых рыб (перефразировано)
Похоже, вы обнаружили, что качество кода не соответствует ожиданиям, на которые вы были настроены.Возможно, из школы, из книг по передовому опыту или из старших разработчиков.
Поработав в нескольких компаниях, мне регулярно советовали проводить модульные тесты, документировать код, использовать систему контроля версий/источников (все хорошие советы, которыми я воспользовался), а затем обнаружил, что те, кто дает эти советы, сами редко следуют этим советам.
Я бы сказал, что у вас сложилось правильное впечатление, что иногда качество кода бывает низким, но это основано только на ваших ожиданиях.Конечно, numpy и другие пакеты являются весьма полезными, даже если они не закодированы в соответствии со стандартом, на который вы рассчитывали.
Стандарты — это мнения, и если вы считаете, что стандарты низкие, то вы можете попытаться помочь улучшить эти стандарты, внося свой вклад, или принять их такими, какие они есть, и обязательно написать код, который послужит примером для новичков, которых вы окажетесь ответственным за один день.
Что касается matplotlib, существует проект по улучшению его «питоновости» - http://www.scipy.org/PyLab
Особенность научных библиотек в том, что они написаны учеными, а не профессиональными разработчиками программного обеспечения.Более того, эти ученые привыкли писать на Фортране.Вопрос в том, что вы предпочитаете: рабочий код или красивый код?
PEP8 — это стиль гид, а не требование стиля.В нем даже говорится, что вы должны «знать, когда следует проявлять непоследовательность».Лично мне некоторые рекомендации в нем не нравятся.я предпочитаю camelCase к snake_case так как я к этому более привык.
И я не часто просматриваю исходный код библиотек, которые использую, за исключением случаев крайней необходимости (например, для отладки).Я бы предпочел документация чтобы указанная библиотека была достаточно адекватной, чтобы мне никогда не приходилось смотреть на источник.
Серьезно, почему вас действительно волнует исходный код? matplotlib выглядит, пока он делает то, для чего предназначен?
Согласен с тобой по поводу пропажи docstrings (при условии, что это общедоступные элементы, а не внутренние), но это не единственный способ документировать библиотеку.
Я считаю, что Python страдает от того, что его слишком активно используют люди, которые не являются программистами (по образованию или профессии), как решение вопроса «нужно немного программировать?»Вот, попробуйте этот простой и зрелый инструмент».
Подобно тому, как PHP добился такого огромного успеха и с таким количеством библиотек с ужасным качеством кода (даже если, конечно, среднее качество кода Python лучше, чем для PHP) - средний пользователь PHP, как и средний пользователь Python, не так уж много программирует. опыт или навыки и очень мало стимулов для самосовершенствования в этом отношении - они намеревались чего-то достичь и, возможно, считали, что это достаточно достойно того, чтобы поделиться с сообществом в виде библиотеки, но чаще всего после того, как работа сделана они не заинтересованы в улучшении кода или в улучшении самих себя (я имею в виду навыки программирования).
Решением может быть введение в репозитории библиотек Python (таких как PyPI) более строгих правил приема предоставленных пакетов — решите это с помощью процесса проверки, целью которого является обеспечение качества — так же, как в основных дистрибутивах Linux есть процесс проверки перед добавлением пакета. в свои репозитории.
PEP8 — это всего лишь соглашение, а не требование.Было бы очень грустно, если бы все программисты Python имел Чтобы придерживаться общего набора правил, мы теряем энтузиазм по малейшему вопросу.
Что касается отсутствующих строк документации — да, они могут помочь при использовании интерактивной справки — но обычно я не возражаю, если есть некоторый документация.Я стараюсь не читать исходный код библиотек, которыми пользуюсь, склонен начинать их модифицировать (переписывать).
Что касается сравнения с другими языками, я думаю, что языковой дизайн здесь играет большую роль.Например, в языке со строгой типизацией, таком как Java, даже если в библиотеке отсутствует хорошая документация, вы все равно можете вывести большую часть функциональности из сигнатур методов.Нет *args бороться с чем-л.
Как насчет коллекции примеров хорошей документации по программному обеспечению?
Хорошие примеры могут привести к общему улучшению немного быстрее, чем случайное блуждание.
Коллекцию можно разделить на такие категории, как:
встроенный документ/страница справки/учебное пособие/справочное руководство, веб-страница/бумага, изображения/нет.
Каждая запись должна содержать несколько слов о почему рецензент находит это хорошим.
(Где:угол stackoverflow?)
Никоу:Я могу ответить только за себя, большая часть моей работы с Python (а также PHP или Ruby, всеми динамическими «скриптовыми» языками) завершена. только для меня - но я всегда публикую его на своем личном сайте, если кто-то еще находит его полезным, но я никогда не прохожу никакую документацию или процесс контроля качества, потому что, пока это работает для меня, я счастлив.
Ну, они являются Открытый исходный код.Таким образом, они также будут развиваться с течением времени, если они достаточно хороши.
Это одна из многих прелестей открытого исходного кода.
Часто нет смысла писать много документации и «хорошего» кода, если вы не знаете, будет ли проект жить дальше.Это было бы просто пустой тратой времени.
Редактировать:Конечно, написание хорошего кода никогда не повредит в первый раз...Но, возможно, во многих случаях достаточно просто «выполнить работу».Я думаю, что в противном случае мы не смогли бы насладиться огромным количеством возможностей, когда дело касается OSS.
Я думаю, что если достаточное количество людей будут вести себя определенным образом, этому может быть какое-то объяснение.Они делают это не случайно, чтобы обидеть вас.
Качество кода * количество комментариев * время = константа
Выбери два !
У меня никогда не было проблем с использованием matplotlib;не могу сказать, что много разглядывал код — это прекрасная библиотека.Делает то, что должен (бесплатно!)
