Кроме php и js тоже есть языки
И что ты этим хочешь сказать? Из за того что названые тобой языки програмирования не единственные в мире то значит коментировать ничего не нужно?
Есть языки со строгим типизированием, тип входных и выходных данных в которых указан явно в сигнатурах. Хорошо написанный код на той же Java, C# и т.д. может отлично обходиться и без комментариев.
Ты сам понял, что сказал? Сигнатура функции - и есть ее описание. А комментарии - хуйня бесполезная.
"Как оно работает" в смысле "что оно делает" -- это лишь малая часть дела, это действительно часто комментировать бесполезно.
Но как оно работает в смысле "почему оно делает именно это" -- вот реальная засада. Да, я вижу что оно делает X, но почему X? Почему не Y, ведь так же быстрее/нагляднее/etc.? Возможно ли это отрефакторить до Z? Или уже пытались, но что-то мешает?
Во сколько-нибудь сложном ПО львиная доля нюансов в коде -- это исправления багов, попытки оптимизации, компромиссы при внедрении новой функциональности, неоконченный рефакторинг и т. д. Никогда это все не будет понятно лишь при взгляде на код.
Но как оно работает в смысле "почему оно делает именно это" -- вот реальная засада. Да, я вижу что оно делает X, но почему X? Почему не Y, ведь так же быстрее/нагляднее/etc.? Возможно ли это отрефакторить до Z? Или уже пытались, но что-то мешает?
Во сколько-нибудь сложном ПО львиная доля нюансов в коде -- это исправления багов, попытки оптимизации, компромиссы при внедрении новой функциональности, неоконченный рефакторинг и т. д. Никогда это все не будет понятно лишь при взгляде на код.
>Во сколько-нибудь сложном ПО львиная доля нюансов в коде -- это исправления багов, попытки оптимизации, компромиссы при внедрении новой функциональности, неоконченный рефакторинг и т. д
А вот на этом моменте я очень рекомендую почитать про историю Лиспа и в частности как на нем писался Яху. Что-то мне подсказывает что данное знание может изменить отношение к некоторым ЯП и вообще к предпочитаемой архетиктуре проектов.
А вот на этом моменте я очень рекомендую почитать про историю Лиспа и в частности как на нем писался Яху. Что-то мне подсказывает что данное знание может изменить отношение к некоторым ЯП и вообще к предпочитаемой архетиктуре проектов.
Если использовать принцип черной коробки и модули с четко определенными данными на входе и выходе, с функциями самостоятельной отладки, отпадает необходимость в костылях и сложном описании. Да и баги появляются только в случаях, не предусмотренных функциями отладки.
Для самодокуменируемого кода нужен особый ЯП. И чем более код спроектирован самодокументируемым — тем более задротней и извращенным является ЯП. При этом это нисколько не отменяет хотя бы минимальные комментарии кода. Классическим примером тут является Haskell — код просто идеально документируется(особенно благодаря системе типов), но вот понимать его от силы могут только несколько избранных. **А уж если Лисп вспомнить, то вообще всё совсем плохо становится.
Любой современный ЯП с явной типизацией подойдет.
Этого недостаточно. Как минимум, надо документировать публичное API. А то очень весело-задорно читать автосгенерированную документацию, где никаких описаний.
А если в коде есть какое-тонеочевидное колдунство не очевидные с первого раза места, их тоже надо комментить.
А если в коде есть какое-то
Дизайнить нужно нормально. Пользователь когда приходит к твоему АПИ у него есть какая-то цель. И ты, как разработчик, должен заранее знать эту цель. Иначе на кой хер ты вообще это все делал? Так вот, пользователь увидев твой АПИ, должен понять методы, котоыре ему подойдут, по сигнатурам. Это достигается правильным именованием, использованием заранее оговоренных подходов, следование единому стилю кода. В большинстве случаев это отлично работает. В крупных открытых проектах конечно от документации не уйдешь, но тогда ее лучше отдельно оформить, в не в комментариях.
Все это, безусловно, надо. Но не понимаю тех, кто топит за отсутствие комментов. Переломитесь что ли написать?
А толку? Вот я недавно поломал проект к хуям, потому что написано было говно, и похуй что с комментом. По комменту не понятно какую именно циклическую ссылку оно развязывает, и схуяли она там изначально. И тесты вроде прошли, и так приложение пашет. Оказалось не полностью пашет. И срать на тот коммент.
Аналогичные ситуации, когда коммент рассказывает о детялях внутренней реализации, потом эта реализация меняется и хук, коммент врет. И никто его не изменил. Потому что задизайнили хуево.
Аналогичные ситуации, когда коммент рассказывает о детялях внутренней реализации, потом эта реализация меняется и хук, коммент врет. И никто его не изменил. Потому что задизайнили хуево.
Все правильно сказал.
Ага блядь, и тесты тоже признак плохого кода, зачем что-то покрывать ими если всё работает?
Я знаю таких программистов, у которых всё работало только в тестах. Их было очень сложно убедить, что что-то не работает у клиентов, потому что ну в тестах же работает.
Ну бывает, тесты могут быть кривыми либо не полными, конечно они являются серебряной пулей, но это на значит что их не нужно писать.
Поэтому кроме юнит-тестов не стоит забывать о функциональном тестировании, на котором попутно проверяется еще и соответствие бизнес-логике. И если не работает или не соответствует, то программист тоже хуй, объективно хуй.
Ну тогда объясните им простую истину:
"Отладка и тестирование может указать на наличие ошибок, но ни на их отсутствие" (с) не помню кто
"Отладка и тестирование может указать на наличие ошибок, но ни на их отсутствие" (с) не помню кто
Заминусили веб разработчики видимо.
Серьёзно?
Такс, не хватает еще 4-х красных линий. Из них 3 должно быть зеленым цветом. И все они перпендикулярные. И одна в форме котенка.
Поєтому когда меня заебали плюсы я ушел к питону, питончик сцуко читается как роман.
З.Ы. Хуйня что иногда роман оказывается детективным и ты даже в конце не понимаешь ГГ гений или долбоёб.
З.Ы. Хуйня что иногда роман оказывается детективным и ты даже в конце не понимаешь ГГ гений или долбоёб.
На плюсах тоже можно красиво писать. Просто программисты любят экспериментировать и колдовать так, что понятно становится только тому, кто писал код и чаще всего он более оптимизирован, чем если бы его писали по общим шаблонам. Пример тебе библиотечные функции: там черт ногу сломит, но работает все гладко, не тратя лишних ресурсов.
Плюсы это феерический язык. Просто писать и читать на нем легко. Но когда начинается особо темная template-магия. Так еще с каждой версией в него пихают овер9000 фич, но скупятся на синтаксические примочки, новые ключевые слова и т.п. Поэтому синтаксис языка становится крайне перегруженным.
Директ линк https://twitter.com/HackerNewsOnion/status/601470152509509632
Чтобы написать коммент, необходимо залогиниться