У многих библиотек Python относительно низкое качество кода?

Ответ 1

Что касается документации, это не только Python. Если есть один фактор, препятствующий более широкому внедрению OSS, IMHO - действительно ужасный уровень документации большинства проектов OSS. Это начинается с уровня кода и распространяется на пользовательские документы. Могу я просто сказать кому-нибудь, кто работает над OSS:

a) Прокомментируйте свой код! Нет такой вещи, как самодокументирующий код!

b) Потратьте не менее 25% бюджета времени проекта на документацию конечного пользователя.

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

Ответ 2

Вместо этого авторы кажутся следовать своему собственному славному соглашению. И иногда соглашения даже не согласуются с одним и тем же файлом библиотеки

Добро пожаловать в замечательный код реального мира!

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

(Ну, лучше, чем средний PHP-проект, очевидно, но это не очень справедливо.)

Ответ 3

Первое, что вам нужно понять, это то, что Python не сформировал spring, полностью сформированный, от головы Guido примерно в версии 2.x. Он вырос за последние двадцать лет.

Фактически, некоторые вещи, которые вы упомянули (unittest, например, и PEP-8), даже не существовали, когда были записаны некоторые стандартные библиотеки.

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

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

Это не значит, что в библиотеках Python нет вещей, которые могут быть улучшены - есть! Но всегда есть компромисс между совершенством и выполнением. Это одна из причин, по которой они говорят: "Практичность превосходит чистоту".

Ответ 4

Это связано с тем, что Python не подкрепляется корпоративным миром, как Java или .Net.

Если я хочу, чтобы моя библиотека Java была повышена Sun, я буду следовать их рекомендациям. Это не относится к Python. Я пишу свой код, люди находят его лучше, и он должен развиваться сам по себе.

Также большинство разработчиков Python от С++, C, Java,.Net и т.д. И они начинают писать производственный код с самого первого дня. Благодаря простоте Python. И порочный круг продолжается.

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

Ответ 5

PEP 8 со временем изменился. Некоторые модули соответствуют более старым рекомендациям. Вы можете видеть это с помощью PIL, в котором используются модули типа "Image", где модуль содержит один основной класс, а не рекомендуемый строчный регистр для имен модулей и в расширениях C, которые используют префикс "c", а не более современные ", _".

Некоторые из библиотек разрабатываются людьми, которые сильно зависят от традиций в других областях, таких как Java и С++. Эти люди чаще используют CamelCase вместо PEP 8, рекомендованных в нижнем регистре_with_underscores.

Ответы здесь не будут полными без ссылки на Закон осетровых: "Девяносто процентов всего дерьмо".

Ответ 6

PEP8 - это руководство стиля , а не требование стиля. Он даже утверждает, что вы должны "знать, когда быть непоследовательными". Лично мне не нравятся некоторые из рекомендаций. Я предпочитаю camelCase до snake_case, поскольку я больше привык к этому.

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

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

Ответ 7

Что касается matplotlib, есть проект для его улучшения "pythoness" - http://www.scipy.org/PyLab

Дело в научных библиотеках заключается в том, что они написаны ученым, а не профессиональными разработчиками программного обеспечения. Moveover, эти ученые используют для записи Fortran. Вопрос в том, что у вас был бы хороший код или красивый код?

Ответ 8

Девяносто процентов [библиотек python] являются crud, но девяносто процентов всего crud

- Закон осетровых (перефразируемый)

Ответ 9

Похоже, вы пришли к выводу, что качество кода не соответствует ожиданиям, которые вы ожидали. Возможно, из школы или книг лучших практик или старших разработчиков.

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

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

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

Ответ 10

Я считаю, что Python страдает от того, что он слишком охотно поднимается на людей, которые не являются программистами (путем обучения или торговли) в качестве решения для "необходимости программирования". Попробуйте этот простой и зрелый инструмент ".

Аналогично тому, как PHP стал таким огромным успехом и с таким количеством библиотек с ужасным качеством кода (даже если предоставлено, среднее качество кода Python лучше для PHP) - средний пользователь PHP, аналогичный среднему пользователю Python, не слишком много опыта программирования или навыков и очень мало стимулов для совершенствования в этом отношении - они намеревались что-то добиться, и, возможно, они считали, что это достаточно достойно, чтобы делиться с сообществом в форме библиотеки, но чаще всего работа выполнена, они не заинтересованы в улучшении кода или лучше себя (в смысле программирования).

Решение может быть для репозиториев библиотеки Python (например, PyPI) иметь более строгие правила приема принимаемых пакетов - обрабатывать это с помощью процесса проверки, целью которого является обеспечение качества - так же, как в основных дистрибутивах Linux есть процесс проверки до добавление пакета в свои репозитории.

Ответ 11

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

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

Ответ 12

Что касается сравнения с другими языками, я считаю, что здесь очень важна разработка языка. Например, на строго типизированном языке, таком как Java, даже если в библиотеке отсутствует хорошая документация, вы все же можете вывести большую часть функциональности из подписи метода. Нет *args, чтобы бороться с.

Ответ 13

Как насчет коллекции примеров хорошего программного обеспечения? Хорошие примеры могут привести к общему улучшению немного быстрее, чем случайная прогулка.
Коллекция может быть разделена на категории, такие как:
inline doc/справочная страница/учебник/справочное руководство, веб-страница/бумага, изображения/нет.
Каждая запись должна содержать несколько слов о том, почему рецензент считает это хорошим. (Где: угол stackoverflow?)

Ответ 14

nikow: я могу ответить только на себя, большинство моих Python (и PHP или Ruby, все динамические "скриптовые" языки) работа выполняется только для меня, но я всегда выпускаю ее на своем личном сайте, если кто-то еще ее найдет полезно, но я никогда не просматриваю какую-либо документацию или процесс QA, потому что, пока она работает для меня, я счастлив.

Ответ 15

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

Это одна из многих красавиц с открытым исходным кодом.

Часто нет смысла писать много документации и "хорошего" кода, если вы не знаете, будет ли проект жить. Это будет просто пустой тратой времени.

Изменить: Конечно, писать хороший код никогда не повредит в первый раз, хотя... Но, возможно, просто "получить работу" достаточно во многих случаях. Я думаю, что в противном случае нам не понравилось бы огромное количество вариантов, когда речь заходит о OSS.

Я думаю, что, если достаточно людей действуют определенным образом, может быть какое-то объяснение. Они не просто случайно делают это, чтобы оскорбить вас.

Ответ 16

Качество кода * количество комментариев * время = постоянное

Выберите два!

У меня никогда не было проблем с использованием matplotlib; не могу сказать, что я много смотрел на код - это прекрасная библиотека. Делает то, что он должен делать (бесплатно!)