Couple of examples are not very helpful. For example, "Command Query Separation". Yes, your functions do exactly one thing, but that thing is so atomic, that it is equal to a command that it is called. In "bad" example maybe the programmer assumes that pop and len actions are bounded and len is always needed after pop is called? No need to separate it and make triple code length.
Example for "Functions Should Do One Thing" is far from excellent also. Code that does something versus code that describes dummy functions without a single call...
Now you can look at good example "Error Handling" and consider "Meaningful Naming". At this point a reader will understand that either meaningful naming could be omitted or good example from Error Handling is not good as it should be.
All the principles are good, but examples are very poor and inconsistent.
Столкнулся с тем, что некоторые научные журналы начали пользоватся подобными системами.
Допустим, есть научная статья [1], в которой вся суть заключена в 3-4 предложениях (Выводы/Заключение). Есть ряд следующих статей, в количестве 500, которые опираются на выводы статьи [1]. Риторический вопрос: Можно ли перефразировать 500 раз, ни разу не повторившись и не искажая смысл написаного? Нужно чётко различать понятия цитирования с указанием источника и плагиат.
А вашу программу можно дописать, чтобы можно было отличать плагиат от цитирования?
Владею устройством от этой компании (Firefly-RK3288). Впечатления больше отрицательные. Комьюнити маленькое, сама компания не в состоянии поддерживать ПО — людей на это не выделили. Версии ядра в линуксе старые. Есть проблемы с драйверами видео, которые не устраняются годами. Причина — закрытые спеки. Сейчас, спустя 5 лет после выпуска устройства, уже можно найти рабочее решение. В начале же сама компания не предоставляет единого рабочего образа, в котором работает всё, перечисленное в характеристиках. Выкатывают устройство, а потом пытаются что-то где-то как-то подлатать.
Нужно 2 дисплея? Вот, пожалуйста, у нас есть образ. Нужно 3D ускорение? Да, у нас оно есть, вот вам другой образ, но там можно подключить только 1 дисплей. Что, eщё нужно GPIO? Это третий образ, в котором не работают другие функции. И т.д.
Загляните к ним на форум.
За такую цену намного лучше взять 2 Rpi4.
Не все производители хотят заморачиваться сертификацией, но это им не мешает выпускать качественный продукт. Видимо, у них такой маркетинг, они делают ставку на узнаваемость «брэнда». Наклейка «органик» не гарантирует лучшего вкуса. Я говорил о ситуации в среднем и имел ввиду супермаркеты мегаполисов. Обилие производителей и наименований зашкаливает, постоянно появляются новые, исчезают старые… надо как-то ориентироваться в этом разнообразии.
С картошкой нам не так повезло, как вам. До проверенного фермера далековато, а больших запасов не делаем, так как хранить негде. Сортов картошки в регионе много. Так что при походе в магазин я примерно представлаю, как выглядит то, что мне надо, но могу и ошибиться. Тут, конечно, не наклейка «био» играет главную роль, а именно внешний вид. Но если рядом лежит «био» и «не-био» картошка, одинаковая на вид, то я предпочту «био», так как обычно она лучше.
Про ГМО ничего не скажу, так как иногда там тонкая грань с чистой селекцией. Возможно, именно её и имел ввиду человек выше. С уверенностью сможет ответить только он. Вот жаль, что «злые ученые» не завезли вкуса и аромата у помидоров, которые долго хранятся. Может, потому их и зовут «злыми»? :)
Скорее всего, здесь очень большую роль играет маркетинг. Я согласен, что вкусовые свойства продуктов могут быть обусловлены разными сортами. Факт в том, что продукты с этикеткой «органик» или «био» в среднем вкуснее и качественнее.
Молоко вкуснее — скорее всего результат сбалансированного корма и правильного содержания коров/коз.
У яиц желтки желтые, а не белёсые — правильное содержание и питание птиц.
Мясо тоже по вкусу и качеству отличается в зависимости от того, чем кормили (или где выпасали) животных/птиц/рыб.
С овощами сложнее, но вряд-ли сорт является единственной причиной различий. Баланс веществ в той же гидропонике очень важен, впрочем как и наличие правильного освещения.
При походе в магазин, я не готов по 10 минут тратить у каждого продукта, читая историю его происхождения (если бы была доступна) :) Выбирая более качественный и вкусный продукт, я ориентируюсь на наклейку типа «био».
Человек, откомментировавший выше, использовал разные сорта, но одни и те же условия выращивания. У разных производителей эти условия могут варьироваться и одинаковые сорта будут иметь разные характеристики. Возможно, «органик» не самый правильный термин для описания более качественного продукта, но другого не завезли.
Бумагу или картон вместо пластика стараются использовать не по финансовым соображениям, а как раз из-за экологии. Только речь идет не об экологии на этапе производства, а о том, что происходит после использования: об утилизации и переработке. Выкинутая бумажка сгниёт за пару лет а полиэтиленовый пакет (без спец. добавок) за 100 лет. Если какая-то зверюшка или морской обитатель решит съесть кусок бумаги (или то, что от него осталось), то ничего не случится в отличии от…
Как выход из положения есть биоразлагаемые пластики и специальные добавки. Но всё это, конечно же, удорожает упаковку. Да, больше энергии, больше воды, дороже производственные линии, сложнее условия хранения.
Потому, что часто сравниваются овощи, выращенные на грядке в тёплых странах с овощами, выращенными в теплице, где-нибудь в Голландии, которым не хватает солнца и которые в магазины попадают очень недозрелыми. Ни вкуса, ни запаха.
Про курицу тоже… и за «био» и за «не био» на птицефабриках строгий контроль. Но одних, например, держат в клетушках размером с саму курицу, а других выпускают погулять и кормят лучшим зерном. Вкус отличается кардинально.
В общем, сильно зависит от того, что с чем вы сравниваете и что конкретно вы подразумеваете под категориями био/не био.
Оба подхода имеют право на жизнь, как по мне. Для перехода от подхода 1 к подходу 2 можно провести рефакторинг, но только тогда, когда процесс оправдан. В теории может настать и случай, когда класс А больше не нужен вовсе и тогда излишние усилия по его унификации не оправдываются. В общем, для выбора подхода должно быть более полное понимание того, как будет развиваться проект. Это задача начальника.
Мне больше понравился ваш пример по унификации обращений к функциям. vdshat ниже тоже пишет о таблицах методов.
Спасибо за пример. Для меня этот код читается тяжело, а переопределения методов ещё и дополнительную путаницу вводят при использовании функции. Возможно, сложность кода росла постепенно, а до рефакторинга руки у авторов не дошли.
Не совсем удачный пример, так как, мне кажется, что вы не следуете принципам «чистого кода» здесь. Разве не следовало написать ещё один метод (def disable_button)? А потом написать ещё один метод, который вызывал бы эти 2 за один раз. Ну и заодно поменять то место, откуда происходил вызов set_readonly.
Может из-за того, что в будущем (для сброса) потребуется больше 1 действия.
Не думал про такой вариант, так как ничего не мешает в будущем этот метод описать. То есть автор заранее закладывает функционал, который, возможно, никогда не будет использован? Это считается правильным подходом в профессиональной среде?
Отсюда следует другой плюс: чтобы изменить эти действия придется внести правку в 1 место, а не искать все места с копипастой по всей кодовой базе.
Неочевидной плюс (IMHO). При изменении наполнения функции (print(«Hello, world!») -> print(«Welcome!»)) придется изменить её название (для соответствия) и тогда точно также копипастой менять по всей кодовой базе. Если же придумать универсальное название, то не будет очевидно что именно она делает.
В первом примере усматривается, что название функции, комментарий и тело функции не синхронизированы в деталях об именовании счётчика.
Согласен, есть какое-то несоответствие в наименованиях. Но надо ли было вводить этот метод?
Обязательно нужен контекст, где этот код написан и каково его назначение.
На счёт контекста не совсем понял, какой именно части Вам не хватает. Можете привести примеры, где подобный подход действительно себя оправдывает? С переиспользованием кода мне всё понятно, но тут…
Функция полезна, если она выполняет какое-то действие. Тут вся польза в комментарии? Тогда вопрос в том, почему надо писать так, а не например так:
cls.last_label = 0 # reset intenal counter
Я тут вижу большой плюс в том, что мне не придется искать описание этой функции/метода где-то ещё и сразу могу понять что именно делает эта строка.
Функция printHelloWorld() нужна в том случае, если определенный набор действий (print(«Hello, world!»)) повторяется больше 2х раз многократно.
Предположим, что так, хотя метод из профессионального проекта вызывается только единожды. Но тут возникает вопрос о том, насколько это уместно. Чем оно лучше print(«Hello, world!»)? Оно так же очень хорошо читается.
При многократном использовании я вижу только один плюс: не сделать ошибку в словах. Но читаемость при этом ухудшается (IMHO). А что на счёт производительности?
Я не являюсь профессиональным программистом, но иногда приходится читать чужой код или писать свой. Читал про принципы, изложенные в книге много раз. Но некоторых моментов понять не могу. Знающие люди, объясните мне, пожалуйста, момент про краткость и самодокументирование функций.
вот пример из реального проекта от профессионалов:
Обязательно! Она придёт с возрастом. Ему сейчас только 12. И базовые знания понадобятся и знания алгоритмов. Ну вот что я ему скажу, если у него элементарных знаний математики не хватает? :) Подожди несколько лет и в 10 классе это будет в учебной программе? Приходится где-то давать просто готовый кусок кода. И он разбирается потихоньку.
По большей части соглашусь с вами. Конечно же для обучения надо использовать те языки и представления, где всё однозначно. Во время моей учёбы в школе с компьютерами был напряг и мы начинали изучение с блок-схем. Там и циклы и условия и переходы.
Но вот есть у меня племянник; очень хочет программировать и у него прям глаза загораются, когда он видит какой-то результат. Использует он питон. Я ему пытаюсь сосватать какие-то азы и базовые понятия, но вижу, если он надолго над этим засядет, то весь его запал сойдёт на нет. Он может написать простенькую программку. Но, к моему сожалению, не всегда до конца понимает, как оно работает. Главное, что у него не пропадает интерес. И иногда ему всё-таки приходится разбираться в деталях. Вот как раз в случаях, когда программа не работает или не даёт ожидаемого результата. И вот тогда к нему по крупицам приходят и какие-то базовые понятия.
Питон со своей огромной базой готовых библиотек и современных туториалов позволяет достигать желаемого результата за короткий срок, подогревая интерес.
Так что, я на примере своего племянника вижу, что питон может быть удачным выбором для неусидчивых школьников в качестве первого языка программирования.
Couple of examples are not very helpful. For example, "Command Query Separation". Yes, your functions do exactly one thing, but that thing is so atomic, that it is equal to a command that it is called. In "bad" example maybe the programmer assumes that pop and len actions are bounded and len is always needed after pop is called? No need to separate it and make triple code length.
Example for "Functions Should Do One Thing" is far from excellent also. Code that does something versus code that describes dummy functions without a single call...
Now you can look at good example "Error Handling" and consider "Meaningful Naming". At this point a reader will understand that either meaningful naming could be omitted or good example from Error Handling is not good as it should be.
All the principles are good, but examples are very poor and inconsistent.
Столкнулся с тем, что некоторые научные журналы начали пользоватся подобными системами.
Допустим, есть научная статья [1], в которой вся суть заключена в 3-4 предложениях (Выводы/Заключение). Есть ряд следующих статей, в количестве 500, которые опираются на выводы статьи [1]. Риторический вопрос: Можно ли перефразировать 500 раз, ни разу не повторившись и не искажая смысл написаного? Нужно чётко различать понятия цитирования с указанием источника и плагиат.
А вашу программу можно дописать, чтобы можно было отличать плагиат от цитирования?
Нужно 2 дисплея? Вот, пожалуйста, у нас есть образ. Нужно 3D ускорение? Да, у нас оно есть, вот вам другой образ, но там можно подключить только 1 дисплей. Что, eщё нужно GPIO? Это третий образ, в котором не работают другие функции. И т.д.
Загляните к ним на форум.
За такую цену намного лучше взять 2 Rpi4.
С картошкой нам не так повезло, как вам. До проверенного фермера далековато, а больших запасов не делаем, так как хранить негде. Сортов картошки в регионе много. Так что при походе в магазин я примерно представлаю, как выглядит то, что мне надо, но могу и ошибиться. Тут, конечно, не наклейка «био» играет главную роль, а именно внешний вид. Но если рядом лежит «био» и «не-био» картошка, одинаковая на вид, то я предпочту «био», так как обычно она лучше.
Про ГМО ничего не скажу, так как иногда там тонкая грань с чистой селекцией. Возможно, именно её и имел ввиду человек выше. С уверенностью сможет ответить только он. Вот жаль, что «злые ученые» не завезли вкуса и аромата у помидоров, которые долго хранятся. Может, потому их и зовут «злыми»? :)
Молоко вкуснее — скорее всего результат сбалансированного корма и правильного содержания коров/коз.
У яиц желтки желтые, а не белёсые — правильное содержание и питание птиц.
Мясо тоже по вкусу и качеству отличается в зависимости от того, чем кормили (или где выпасали) животных/птиц/рыб.
С овощами сложнее, но вряд-ли сорт является единственной причиной различий. Баланс веществ в той же гидропонике очень важен, впрочем как и наличие правильного освещения.
При походе в магазин, я не готов по 10 минут тратить у каждого продукта, читая историю его происхождения (если бы была доступна) :) Выбирая более качественный и вкусный продукт, я ориентируюсь на наклейку типа «био».
Человек, откомментировавший выше, использовал разные сорта, но одни и те же условия выращивания. У разных производителей эти условия могут варьироваться и одинаковые сорта будут иметь разные характеристики. Возможно, «органик» не самый правильный термин для описания более качественного продукта, но другого не завезли.
Как выход из положения есть биоразлагаемые пластики и специальные добавки. Но всё это, конечно же, удорожает упаковку. Да, больше энергии, больше воды, дороже производственные линии, сложнее условия хранения.
Про курицу тоже… и за «био» и за «не био» на птицефабриках строгий контроль. Но одних, например, держат в клетушках размером с саму курицу, а других выпускают погулять и кормят лучшим зерном. Вкус отличается кардинально.
В общем, сильно зависит от того, что с чем вы сравниваете и что конкретно вы подразумеваете под категориями био/не био.
Мне больше понравился ваш пример по унификации обращений к функциям. vdshat ниже тоже пишет о таблицах методов.
Не совсем удачный пример, так как, мне кажется, что вы не следуете принципам «чистого кода» здесь. Разве не следовало написать ещё один метод (def disable_button)? А потом написать ещё один метод, который вызывал бы эти 2 за один раз. Ну и заодно поменять то место, откуда происходил вызов set_readonly.
Неочевидной плюс (IMHO). При изменении наполнения функции (print(«Hello, world!») -> print(«Welcome!»)) придется изменить её название (для соответствия) и тогда точно также копипастой менять по всей кодовой базе. Если же придумать универсальное название, то не будет очевидно что именно она делает.
Согласен, есть какое-то несоответствие в наименованиях. Но надо ли было вводить этот метод?
На счёт контекста не совсем понял, какой именно части Вам не хватает. Можете привести примеры, где подобный подход действительно себя оправдывает? С переиспользованием кода мне всё понятно, но тут…
Я тут вижу большой плюс в том, что мне не придется искать описание этой функции/метода где-то ещё и сразу могу понять что именно делает эта строка.
Предположим, что так, хотя метод из профессионального проекта вызывается только единожды. Но тут возникает вопрос о том, насколько это уместно. Чем оно лучше print(«Hello, world!»)? Оно так же очень хорошо читается.
При многократном использовании я вижу только один плюс: не сделать ошибку в словах. Но читаемость при этом ухудшается (IMHO). А что на счёт производительности?
вот пример из реального проекта от профессионалов:
Метод не переиспользуется. В чём смысл из одной строки делать две, да ещё и описывать новый метод для этого?
Где надо остановиться? Надо ли из кода:
делать нечто такое:
чем оно лучше?
Автор, видимо, пользуясь своей же методикой, постепенно делает рефакторинг книги :) «Чистый текст» про «чистый код».
Но вот есть у меня племянник; очень хочет программировать и у него прям глаза загораются, когда он видит какой-то результат. Использует он питон. Я ему пытаюсь сосватать какие-то азы и базовые понятия, но вижу, если он надолго над этим засядет, то весь его запал сойдёт на нет. Он может написать простенькую программку. Но, к моему сожалению, не всегда до конца понимает, как оно работает. Главное, что у него не пропадает интерес. И иногда ему всё-таки приходится разбираться в деталях. Вот как раз в случаях, когда программа не работает или не даёт ожидаемого результата. И вот тогда к нему по крупицам приходят и какие-то базовые понятия.
Питон со своей огромной базой готовых библиотек и современных туториалов позволяет достигать желаемого результата за короткий срок, подогревая интерес.
Так что, я на примере своего племянника вижу, что питон может быть удачным выбором для неусидчивых школьников в качестве первого языка программирования.