Comments 21
В статье один пример и тот с ошибкой
Нужен тег "пост сгенерирован AI"
Очень сильно похоже на выдачу chatGPT.
Привет! Делал пост в телеграме пару месяцев назад. Был запрос о более глубоком рассмотрении темы насмотренности. Постарался написать статью (на основе того поста) в более академическом стиле и с добавлением пунктов к рекомендациями. Возможно это и считывается как ChatGPT, но это не более чем стилизация.
Но отмечу, я ничего не имею против использования ChatGPT)
Учитесь и расширяйте кругозор - звучит гораздо лучше. А насмотренность это прямая дорога к карго-культу. Всё будет красиво и чисто, но есть нюанс.
![](https://habrastorage.org/getpro/habr/comment_images/d0a/2ab/764/d0a2ab764d2ca66e0b1900772b6d25f2.jpg)
Насмотренность это часть кругозора. И конечно насмотренность включает в себя не только форматирование кода, но и как написано в статье: «код, который не только выполняет свою функцию, но и легко читается, понятен для других разработчиков, легко масштабируется, тестируется и поддерживается в будущем» .
И даже это, только часть того, что делает код хорошим.
Каждый разработчик должен стремиться к тому, чтобы его код был не только функциональным, но и элегантным, читаемым и легко поддерживаемым для себя и других участников команды.
Теперь в вакансиях будут писать в навыках "must have: насмотренность от 5 лет" :-)
Привет! Почему в статье нет поинта, что хороший код - это безопасный код?
Безопасная разработка становится уже признаком "хорошего тона". Код ревьюится на предмет безопасности - это тоже улучшает "насмотренность".
Привет! Соглашусь что безопасный код не менее важен чем чистый и тд. Хорошее дополнение, постараюсь добавить в статью)
с кодом и правда чуть больше нюансов, чем с визуальным дизайном. оценить что код хороший сложнее, чем просто взглянуть на функции или их совокупность
Привет! Согласен)
Хороший код, довольно сложно написать, так как нам еще часто приходится выбирать между безопасностью, скоростью и чистотой. Конечно, можно учитывать все три момента, и искать золотую середину, но на практике часто бывает перекос в одну из сторон.
Безопасность кода - это про функциональность.
Если код "дырявый", то спустя время, когда уязвимость в коде проэксплуатируют, функциональность будет стремиться к нулю, к сожалению. Нефункциональный код вряд ли кому-то нужен.
Ну, не занаю.
Пример в начале статьи не просто плохой, а очень плохой.
И наборот, я бы назвал пример хорошего кода плохим кодом, а хорошего - плохим хорошим. Потому, что при первом взгляде на верхний код однозначно понятно, что он делает и что возвращает, а на нижний - непонятно.
Серьёзно? Верхний код вводит в заблуждение, будто эти строки выполняют какие-то значимые действия. Хотя по сути они перекладывают из пустого в порожнее.
Я не знаю, на каком языке это написано, наверное псевдокод, но по питонячьему смысл верхнего кода такой:
Проверить, что значением value является логическое True, если да, вернуть логическое True
В любом другом случае вернуть логическое False
Для нижнего кода смысл просто вернуть value.
Таким образом, если скажем значение value например "test_value", верхний код вернет False, нижний код вернет "test_value".
По моему так.
Я понимаю так, что пример написан на строго типизированном языке, где value имеет тип bool и ничего кроме true/false принимать не может.
Но и для питона подобный кусок кода я бы не назвал хорошим. Хорошим для этого случая будет:
return value is True
Эта строчка сделает именно то, что вы прописали в своём комментарии, безо всяких if и else
Данный код почти наверняка написан на старом добром С, на стандартном языке который всем понятен и на котором как-то пусть даже худо-бедно но могут программировать все.
Если это так то в данном примере value как раз таки может быть равен любому значению и быть почти любого встроенного типа - возвращаемое значение будет просто приведено к типу int (целое со знаком, типичного для текущей архитектуры размера но не меньше 2 байта). Тип bool же вообще не является частью языка С и поэтому почти во всех компиляторах не является встроенным типом, а определяется в заголовочных файлах стандартной библиотеки (тип _Bool доступный у многих современных С-компиляторов и связанные с ним хитрости мы тут не рассматриваем - в любом случае использовать его в своих программах в явном виде почти никогда не следует). После выхода из функции это значение может даже так и оставаться любым, просто далее во всех логических выражениях результат чаще всего будет просто проверяться на равенство 0 (0 там определяется как "false", но при большом желании можете сделать наоборот), а для всех остальных значений соответствующих "true" конкретное значение будет тогда уже не важно (впрочем, gcc, например, при приведении к bool автоматически заменяет все значения выше 1 или меньше 0 на 1 чтобы из него потом можно было набирать битовые маски без классического волшебного "!!value").
Поэтому для С в данном случае никаких дополнительных действий не требуется, и самый короткий код - он же и самый правильный.
Насмотренность в разработке: путь к чистому и качественному коду