03.12.2017, 17:44
"Как оно работает" в смысле "что оно делает" -- это лишь малая часть дела, это действительно часто комментировать бесполезно.
Но как оно работает в смысле "почему оно делает именно это" -- вот реальная засада. Да, я вижу что оно делает X, но почему X? Почему не Y, ведь так же быстрее/нагляднее/etc.? Возможно ли это отрефакторить до Z? Или уже пытались, но что-то мешает?
Во сколько-нибудь сложном ПО львиная доля нюансов в коде -- это исправления багов, попытки оптимизации, компромиссы при внедрении новой функциональности, неоконченный рефакторинг и т. д. Никогда это все не будет понятно лишь при взгляде на код.
Но как оно работает в смысле "почему оно делает именно это" -- вот реальная засада. Да, я вижу что оно делает X, но почему X? Почему не Y, ведь так же быстрее/нагляднее/etc.? Возможно ли это отрефакторить до Z? Или уже пытались, но что-то мешает?
Во сколько-нибудь сложном ПО львиная доля нюансов в коде -- это исправления багов, попытки оптимизации, компромиссы при внедрении новой функциональности, неоконченный рефакторинг и т. д. Никогда это все не будет понятно лишь при взгляде на код.
>Во сколько-нибудь сложном ПО львиная доля нюансов в коде -- это исправления багов, попытки оптимизации, компромиссы при внедрении новой функциональности, неоконченный рефакторинг и т. д
А вот на этом моменте я очень рекомендую почитать про историю Лиспа и в частности как на нем писался Яху. Что-то мне подсказывает что данное знание может изменить отношение к некоторым ЯП и вообще к предпочитаемой архетиктуре проектов.
А вот на этом моменте я очень рекомендую почитать про историю Лиспа и в частности как на нем писался Яху. Что-то мне подсказывает что данное знание может изменить отношение к некоторым ЯП и вообще к предпочитаемой архетиктуре проектов.
Для самодокуменируемого кода нужен особый ЯП. И чем более код спроектирован самодокументируемым — тем более задротней и извращенным является ЯП. При этом это нисколько не отменяет хотя бы минимальные комментарии кода. Классическим примером тут является Haskell — код просто идеально документируется(особенно благодаря системе типов), но вот понимать его от силы могут только несколько избранных. **А уж если Лисп вспомнить, то вообще всё совсем плохо становится.
Этого недостаточно. Как минимум, надо документировать публичное API. А то очень весело-задорно читать автосгенерированную документацию, где никаких описаний.
А если в коде есть какое-тонеочевидное колдунство не очевидные с первого раза места, их тоже надо комментить.
А если в коде есть какое-то
Дизайнить нужно нормально. Пользователь когда приходит к твоему АПИ у него есть какая-то цель. И ты, как разработчик, должен заранее знать эту цель. Иначе на кой хер ты вообще это все делал? Так вот, пользователь увидев твой АПИ, должен понять методы, котоыре ему подойдут, по сигнатурам. Это достигается правильным именованием, использованием заранее оговоренных подходов, следование единому стилю кода. В большинстве случаев это отлично работает. В крупных открытых проектах конечно от документации не уйдешь, но тогда ее лучше отдельно оформить, в не в комментариях.
А толку? Вот я недавно поломал проект к хуям, потому что написано было говно, и похуй что с комментом. По комменту не понятно какую именно циклическую ссылку оно развязывает, и схуяли она там изначально. И тесты вроде прошли, и так приложение пашет. Оказалось не полностью пашет. И срать на тот коммент.
Аналогичные ситуации, когда коммент рассказывает о детялях внутренней реализации, потом эта реализация меняется и хук, коммент врет. И никто его не изменил. Потому что задизайнили хуево.
Аналогичные ситуации, когда коммент рассказывает о детялях внутренней реализации, потом эта реализация меняется и хук, коммент врет. И никто его не изменил. Потому что задизайнили хуево.
Ну бывает, тесты могут быть кривыми либо не полными, конечно они являются серебряной пулей, но это на значит что их не нужно писать.
Поэтому кроме юнит-тестов не стоит забывать о функциональном тестировании, на котором попутно проверяется еще и соответствие бизнес-логике. И если не работает или не соответствует, то программист тоже хуй, объективно хуй.
Такс, не хватает еще 4-х красных линий. Из них 3 должно быть зеленым цветом. И все они перпендикулярные. И одна в форме котенка.
На плюсах тоже можно красиво писать. Просто программисты любят экспериментировать и колдовать так, что понятно становится только тому, кто писал код и чаще всего он более оптимизирован, чем если бы его писали по общим шаблонам. Пример тебе библиотечные функции: там черт ногу сломит, но работает все гладко, не тратя лишних ресурсов.
Плюсы это феерический язык. Просто писать и читать на нем легко. Но когда начинается особо темная template-магия. Так еще с каждой версией в него пихают овер9000 фич, но скупятся на синтаксические примочки, новые ключевые слова и т.п. Поэтому синтаксис языка становится крайне перегруженным.
