Комментарии 9
Ребят, а куда переехали технические статьи?
Вы решаете, что будете использовать комментарии, чтобы объяснить, почему код написан именно так, как написан, а не описывать, что делает этот код.
Я правильно понял? — комментарии должны описывать ИДЕИ, заложенные в код и описывать на высоком, можно сказать — "философском" уровне.
Вспомнились рекомендации Боба Мартина с книги «Чистый код» (или «Совершенный код»):
Хорошо написанный код сам себя объясняет, и необходимость в комментариях почти отпадает.
Лучший комментарий — не написанный комментарий, когда код понятен сам по себе без лишних объяснений.
Каждый раз, когда вы используете комментарии для объяснения кода, вы признаете, что вам не удалось написать понятный код и вы используете «костыли» в виде дополнительных объяснений.
Исключения, конечно, есть, но их не так много (для использования документаторов и автоподсветки IDE, для указания копирайта и т.д.)
Хорошо написанный код сам себя объясняет, и необходимость в комментариях почти отпадает.
Лучший комментарий — не написанный комментарий, когда код понятен сам по себе без лишних объяснений.
Каждый раз, когда вы используете комментарии для объяснения кода, вы признаете, что вам не удалось написать понятный код и вы используете «костыли» в виде дополнительных объяснений.
Исключения, конечно, есть, но их не так много (для использования документаторов и автоподсветки IDE, для указания копирайта и т.д.)
Не считаю себя экспертом или оракулом, но как разработчик стараюсь придерживаться следующих правил в коде:
— Главные принципы хорошего кода — это KISS и DRY. Т.е. код должен быть максимально простым и понятным и в то же время в коде нужно избегать повторений и чтобы изменения происходили в минимальном количестве мест
— Архитектура приложения должна «расти» вместе с приложением: проект может начинаться как монолитный, далее может понадобится выделить сервисы, общие компоненты, реализовать взаимодействия и прочее. Соблюдение KISS и DRY позволяет достичь это сравнительно безболезненно.
— Хороший разработчик должен следить и пробовать передовые технологии, но в реальных проектах использовать технологии 1-2х летней давности (когда они становятся стабильными и проходит «пена» инновационности). Основная цель использования технологий — сократить время разработки и обеспечить стабильную работу системы. (К примеру активно применять .Net Core я планирую только через 1-2 года, а пока всё ещё сижу на классическом ASP.Net MVC/WebAPI)
— Тесты важны и нужны. Как минимум общие и сложные вещи в коде должны быть ими покрыты. С другой стороны я не сторонник TDD (вернее сторонник его только для написания сервисов, т.к. их сложно тестировать).
— Паттерны нельзя выучить, они должны получаться сами, когда ты пишешь код. Использование паттернов — скорее вопрос архитектуры, чем разработки.
— Код пишется для того, чтобы заработать деньги и удовлетворить клиентов. Если ваши предложения экономически невыгодны, то нужно наступить себе на горло и делать то, что принесёт большую прибыль.
— Универсального кода не существует. Код должен делать только одну специфичную вещь. Если стараться написать один код на все случаи жизни, то он будет сложным, менее безопасным и труднее в поддержке.
— Разработчик не должен бояться использовать чужой опыт и разумно копировать код. С другой стороны внешние библиотеки и плагины должны подключаться только в случае крайней необходимости, а простые вещи должны быть реализованы специфично для данного проекта. (К примеру не нужно прикручивать мощный табличный плагин вроде jqGrid или чего-то более современного только чтобы отобразить простые нередактируемые данные и сделать пагинацию).
— Главные принципы хорошего кода — это KISS и DRY. Т.е. код должен быть максимально простым и понятным и в то же время в коде нужно избегать повторений и чтобы изменения происходили в минимальном количестве мест
— Архитектура приложения должна «расти» вместе с приложением: проект может начинаться как монолитный, далее может понадобится выделить сервисы, общие компоненты, реализовать взаимодействия и прочее. Соблюдение KISS и DRY позволяет достичь это сравнительно безболезненно.
— Хороший разработчик должен следить и пробовать передовые технологии, но в реальных проектах использовать технологии 1-2х летней давности (когда они становятся стабильными и проходит «пена» инновационности). Основная цель использования технологий — сократить время разработки и обеспечить стабильную работу системы. (К примеру активно применять .Net Core я планирую только через 1-2 года, а пока всё ещё сижу на классическом ASP.Net MVC/WebAPI)
— Тесты важны и нужны. Как минимум общие и сложные вещи в коде должны быть ими покрыты. С другой стороны я не сторонник TDD (вернее сторонник его только для написания сервисов, т.к. их сложно тестировать).
— Паттерны нельзя выучить, они должны получаться сами, когда ты пишешь код. Использование паттернов — скорее вопрос архитектуры, чем разработки.
— Код пишется для того, чтобы заработать деньги и удовлетворить клиентов. Если ваши предложения экономически невыгодны, то нужно наступить себе на горло и делать то, что принесёт большую прибыль.
— Универсального кода не существует. Код должен делать только одну специфичную вещь. Если стараться написать один код на все случаи жизни, то он будет сложным, менее безопасным и труднее в поддержке.
— Разработчик не должен бояться использовать чужой опыт и разумно копировать код. С другой стороны внешние библиотеки и плагины должны подключаться только в случае крайней необходимости, а простые вещи должны быть реализованы специфично для данного проекта. (К примеру не нужно прикручивать мощный табличный плагин вроде jqGrid или чего-то более современного только чтобы отобразить простые нередактируемые данные и сделать пагинацию).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Извилистый путь разработчика