Комментарии 21
Пожалуй, самое отвратительное – большая вложенность if в функциях, часто ещё и совместно с else, вместо проверок от противного с возвратом из функции в случае несоответствия
) а кто-то считает отвратительным множество возвратов в методе
С расширениями подсветки синтаксиса и форматирования структуры даже несколько if () {} else {} смотрятся отлично и отлично читаются, если ветвление умещается на экран.
Два if-else уже не смотрятся адекватно. А недавно ревью делал - адекватный вроде мид с многолетним опытом нарисовал if-else-switch на 15 строк. Хотя в его случае - решение было невменяемое, но приемлемое. Специфика задачи.
else if — вполне себе адекватная замена switch case, только без goto "под капотом".
Например, парсинг **argv.
if (flag == 'a') {
foo_option_a();
} else if (flag == 'b') {
foo_option_b();
} else if (flag == 'c') {
foo_option_c();
}Что здесь не читабельного???
если вы выкинете else то код станет читабельным а проседания по производительности не будет
Проседание будет, если мы хоть раз попадаем в первый или второй if. В этом случае ветки else вообще не выполнятся. А в варианте без else всегда будут выполняться ровно три проверки, если, конечно, какой-нибудь умный компилятор не догадается, что flag не меняется и проверки взаимоисключающие. И чем медленнее проверки в if - тем сильнее будет проседание. Хотя в вышеприведённом примере про argv разница скорее всего несущественна.
Это хороший способ определить можем ли мы записать конструкцию в одну строку инлайново, но с логическими операторами явно не тот случай.
Если покрывать код тестами и пытаться избегать конфликтов, можно обнаружить, что даже однократное использование else является "узким" местом.
В подавляющем большинстве случаев (подчеркну, что не в 100%) можно использовать однократный if, и это будет самым лаконичным решением, а также поможет избежать конфликтов и упростит написание тестов.
Все рекомендации не абсолютны. Читал китайский код, в котором на 40 строчек кода было написано 20 выночных функций. Я бы предпочел хорошо оформленную иерархию вложенных операторов if
А вот предположим, что вам нужно было бы покрыть этот код тестами. Вы всё ещё предпочли бы иерархию if-ов? )
Методы то эти приватные, скорее всего, в тестировании все равно ничего не изменится
в функциях там было как правило, по несколько строчек. Я бы это пережил.
В первую очередь тут надо сверяться с целесообразностью. Я полагаю, что у китайца был набор функций, написанный для других вещей, и он не стал заморачиваться и накопипастил. Себе время сэкономил.
Но проблема была в том, что этот код был написал в 2011 году, автоматически выгружался из системы вместе с документом и преобразовывал его под локальные настройки. А когда возвопили, что вшитый код порет херню, а иногда вообще не работает, китайца обнаружили уволенным, техподдержка заявила, что будет исправлять в следующий апдейт, то есть, через полгода, и я пошел разбираться с ошибками, то времени просто разобраться, как же он предполагал преобразовывать документ и пересчитывать суммы, ушла уйма. В итоге я только шесть функций, написанных узкоглазым, оставил, остальное написал в теле через условные операторы.
Хорошо, доступно, понятно.
Когда тему разжевывают со всех сторон - это выглядет куда лучше, чем просто один пример или одно предложение на одну ситуацию.
А у вас можно заказывать разработку документации? (Не все же обучать могут, я вот например не учитель, но документация по style guide и best practices в команде нужна)
Ещё накину про переменные:
Соблюдать наименьшее расстояние между объявлением переменной и местом ее использования
Следить за тем, чтобы в коде не было неиспользуемых переменных или ни на что не влияющих присваиваний значений.
Названия переменных всегда с маленькой буквы - названия классов с большой (может это конечно уже вкусовщина)
Есть инструменты статического анализа, проверки стилистической нормы, флаги компилятора на выявление таких штук, как неиспользуемые переменные. В GCC, например:
gcc -std=* -pedantic -Wall
-Wextra -WerrorЕсть ещё много других полезных штук, например, -Wstack-protector
Спасибо, интересно. Я до этого в серьезное программирование ещё не влезал. Все только веб, да веб, где вот эта вот динамическая типизация и на память оперативную по большому никто о ней даже не знает ничего. Там такого нет, чтобы в интерпретаторе были встроены линтеры и проверки пременных, там либо только отдельные opensource либы с гитхаб, причем разные и например новичку, чтобы разобраться какая что делает нужно съесть сапог, либо все у JetBrains.
Из-за этого я сильно подсел на IDE, которая подсвечивает весь сомнительный синтаксис. Но я думаю мои коллеги меня ругают мысленно за то, что без IDE, я очень многого чего не умею "сам" делать.
Не историю коммитов в GIT полную посмотреть из cli, ни линтер по-человечески к PHP подключить (пробовали несколько раз со студентом подключить - но это все не то). И GUI для GIT тоже не видел ещё отдельного удобного инструмента.
Для Web есть Type Script (TS). Там статическая типизация и все сильно упрощается и уже не получится делать абы как. Придется стремиться делать правильно. Хотя...)
Да, не, давай без не "Хотя". Если уж начинать, так и впредь делать правильно.
Для меня как для нуба, единственное что не хватает, так это документации о возможностях современных сборщиков, о том к какому движку из можно подключить, как настроить IDE для автоматической обработки алиасов от webpack в scss.
JavaScript развивался долгое время, а пока кто-то тут прогал на пхп и знал только разве что как jQuery подключить, в JS уже произошло много всего и сейчас трудно аккумулировать все эти изменения и то к чему они привели.
С TS вроде бы все более менее хорошо. JetBrains нормально с ним умеет, а не только vscode. Я вот недавно пару тройку интерфейсов написал. Порог входа конечно большой, особенно если ты заядлый пофигист, был.
Но я думаю мои коллеги меня ругают мысленно за то, что без IDE, я очень многого чего не умею "сам" делать.
Глупости. Это синдром самозванца назыввется. Коллегам глубоко фиолетово, у них свои задачи, свои проблемы.
Не историю коммитов в GIT полную посмотреть из cli
Зачем делать неудобно, когда есть способ делать удобно? IDE - это не блажь, это не колесики детские на велике, без которых настоящий альфа-программач должен выжимать 100кмч в гору. IDE это штука, которая экономит очень дорогое время разработчика, позволяя не тратить его на то, что можно сделать быстрее, оптимальнее, удобнее, и тд. Кому нужна эта рутина? Ну а если вдруг случится ситуация, когда у тебя есть только голый терминал и тебе нужно посмотреть историю коммитов в гите, чтобы спасти планету...ну вбей в гугл, там будут команды, делов на 5 минут.
Не нужно уметь все и хорошо. Так не бывает. То, что не делаешь постоянно, все равно забывается. Не нужно занижать себе самооценку, додумывая за других, за что они тебя должны ругать. Почему вообще они должны тебя ругать? Им зарплату урезают чтоли, есди ты гит не через cli ковыряешь? Ты не должен знать все команды гита, не должен знать даже все функции в пхп или жс. Ты не должен знать наизусть документацию. Ты должен знать, что есть такие и такие возможности, и все. А какие параметры у какой функции и тд можно в любой момент найти в документации.
А на аргумент подстебывающего коллеги "а если завтра интернет пропадет, что будешь делать? " смело парируй "идти на завод вместе с тобой, потому что иначе наши продукты не имеют смысла, мы веб-разработчики, алё".
Подстебывающий коллега, кстати, тоже не знает наизусть документацию.
Следить за тем, чтобы в коде не было неиспользуемых переменных или ни на что не влияющих присваиваний значений.
Об этом по хорошему, должен предупреждать компилятор/IDE.
«В идеальном случае количество аргументов функции равно нулю. Далее следуют функции с одним аргументом и с двумя аргументами. Функций с тремя аргументами следует по возможности избегать. Необходимость функций с большим количеством аргументов должна быть подкреплена очень вескими доводами».
Может не стоит цитаты из чистого кода приписывать Глебам Михеевым?
Взяли и почти дословно пересказали фрагмент "Чистого кода" Мартина. Круто, что скажешь.
Устраняем популярные изъяны в коде — чек-лист ошибок junior-разработчиков