Comments 43
тот кто вызывает, должен знать, что он хочет.
если вы аргументируете тем, что последний, в данном случае, параметр может быть неизвестен вызывающему, то флаг вам в руки и удачи )
ну так а как без if он там выберет что хочет?
Зависит от контекста, если это решает пользователь приложения создавать временный или постоянный, то конечно без if мы не сможем скорее всего выбрать, не рассматривая совсем экзотические случаи.
Ну а вдругих случаях, нам должно быть известно уже во время написания программы хотим ли бы в конкретном месте временный файл или постоянный.
плюс, читающему код будет понятнее, а что тут, собственно, происходит - логика описана именами функций
а зачем их запоминать? В этом же и суть - читаешь код, видишь функцию с именем, примерно подходящим под искомое решение, лезешь внутрь и правишь/дебажишь/смотришь только там, игнорируя остальные.
Что до сложнопереводимых имен - вот как раз когда функция короткая, ей можно придумать короткое же имя.
ну и обратная сторона - вот у нас есть функция на 700 строк, которая считает емкость wifi сети. Какая там в ней логика, фиг поймешь, особенно через год. Натурально надо день в отладке провести просто чтоб понять, что происходит
Правочки подьедут в логику - кровавыми слезами умоешься, правя везде. Захочешь фичу добавить - читай весь файл/юнит, чтобы чем-то воспользоваться (причем половина будет копипаст). Каша ради несущественной оптимизации
"Еще и комментировать код не надо, кек. Зачем, я же названия раздаю как боженька!" <- и от Д`Артаньяна идет явный запашок
эээ.. в этом же и суть коротких однозначных функций - не надо править везде, надо править толь-ко в одном месте - single point of truth, dry и прочее
Комментирование кода часто бессмысленное дело, т.к. код меняется, а каменты - нет
понятно, что нужен баланс. Но чаще всего-то, этот флаг добавляется и развивается во много флагов
Тут скорее функция или метод как действие. Выделение малого действия, описание возможных его вариантов. Раньше видал байт как набор флагов, из которых дергали побитовым сложением.Однозначные же функции переусложняют чтение и многократно перепечатывают одинаковые куски текста. (ну если там вообще что-то похожее по смыслу, что имело смысл быть запиханным в одну функцию => надо править только в одном месте - single point of truth, ага)
Вот откуда еще, кстати, взялась мысль, что сложнопереводимая = короткая? Наоборот, с автоподстановкой можно не экономить!
Насчет комментариев - это смотря как готовить. К примеру, если оставлять комментарием развернутое описание функции, параметров и флагов в заголовке, а затем откомментировать только нетривиальные места - они не склонны к изменению (попробуй повтори). Тогда еще и документуха в один прогон соберется.
Решительно не понима. Ваших доводов.
Однозначные же функции переусложняют чтение и многократно перепечатывают одинаковые куски текста.
Это прямо противоречит тому, о чем я писал:) Если есть одинаковые куски кода, они как раз и сводятся в _одну функцию
Вот откуда еще, кстати, взялась мысль, что сложнопереводимая = короткая? Наоборот, с автоподстановкой можно не экономить!
э.. я такого не говорил
я наоборот говорил, что простая логика внутри функции приведет к простому же имени данной функции
К примеру, если оставлять комментарием развернутое описание функции, параметров и флагов в заголовке, а затем откомментировать только нетривиальные места - они не склонны к изменению (попробуй повтори)
это в теории
на практике часто код меняется, а каменты нет
Еще кекну над "днем на функцию на 700 строк" - ну реально, если лид такой код пропустил - его надо увольнять. Не подроблено на "действия" (функции), ничего не описано нигде и никем - "НО ОНО ЖЕ РАБОТАЕТ", да? Гугл и прочая свои кодгайды для лошков делает, видать
Обычно, когда вы видите этот контекст, вы можете определить во время компиляции, по какому пути пойдет код. Если это так, то всегда используйте этот паттерн.
Первый же совет — ржач полный. Иф в методе убрал, а вызываю как? Наоборот, имхо лучше один метод, отвечающий за запись, с параметром (если он один — вообще прекрасно)
Было:
<button onClick={FileUtils.createFile("name.txt", "file contents", false)}>
Create Permanent File
</button>
<button onClick={FileUtils.createFile("name.txt", "file contents", true)}>
Create Temporary File
</button>Стало:
<button onClick={FileUtils.createPermanentFile("name.txt", "file contents")}>
Create Permanent File
</button>
<button onClick={FileUtils.createTemporaryFile("name.txt", "file contents")}>
Create Temporary File
</button>
Ага, только вместо одной функции с if, мы теперь имеем две функции, скорее всего с реализацией по типу copy-paste, что будет плодить ошибки. А если там есть общие части, которые мы вынесем, например, в commonCreateFile(), то у нас вместо 1 функции уже будет три. Ну, что, гениально. Как создать себе работу на ровном месте…
Это называется рефакторинг.
Вы видели пример? Это для тех функций, у которох на верхнем уровне иф. Вы видите, что в этой функции просто два независимых блока кода без общей логики? Как вы вообще программистом стали с таким низким уровнем внимательности?
public static void createFile(String name, String contents, boolean temporary) {
if(temporary) {
// save temp file
} else {
// save permanent file
}
}Но даже "ужасный" пример, который вы привели - это хорошо, а большая функция с кучей разных ответственностей - это плохо. Разнос на два метода может помочь проанализировать функцию и выделить дублирующийся код в отдельный метод с понятным названием.
Но я слышал, что некоторым людям момент, когда надо подумать минутку - это слишком сложно и они хотят просто кодить.
Вы видите, что в этой функции просто два независимых блока кода без общей логики?
Вы не можете ни подтвердить это, ни отрицать. Автор скромно схлопнул реальный код в комментарий. Блок "save temp file" может быть точно таким же как "save permanent file" на 90-99%. Ну, вот - написали как написали.
а большая функция с кучей разных ответственностей - это плохо.
разделять ответственность тоже нужно разумно.
Разнос на два метода может помочь проанализировать функцию и выделить дублирующийся код в отдельный метод с понятным названием.
может да, а может нет. Точнее - не обязательно разносить на два метода, чтобы можно было выделить дублирующийся код.
Как вы вообще программистом стали с таким низким уровнем внимательности?
троллинг не засчитан.
Но я слышал, что некоторым людям момент, когда надо подумать минутку - это слишком сложно и они хотят просто кодить.
такое тоже бывает.
В последнем примере вместо проверки на null будет проверка на defaultValue
Чем это лучше?
Разделить на два класса?
TmpFile.new("file_name.txt").create
RegularFile.new("file_name.txt").create
Решение: Разделите метод на два новых метода. Вуаля, if исчезло.
в параметрах иногда true/false незначительно изменяют кое-какие например флаги. Т.е. убрав if, мне придётся дублировать полностью намного сложнее код.
Какое-то искуственное придумывание проблемы на пустом месте.
Одинаковый код можно вынести в еще один метод. Итого: + 2 метода в место одного if. )
Дорогой автор, даже, если вам не нравятся другие мнения, всё равно стоит к ним прислушаться. Объясню почему.
В первом случае вы привели тривиальный случай, который 1:1 повторяет if оператор - те. вы заменили этот if оператор на две функции. А что делать, если внутри функции три и более if оператора? Заменять их на n! количество функций? У меня названий не хватит, если я вместо 4-х if(ов) 24 функции напишу, каждая из которых отдельную ситуацию воспроизведёт.
Это первое. Второе. Как бы вы не упрощали, вам всё равно выше по хирархии вызовов надо будет де-то принимать решение, какую из реализаций вызывать. Поэтому видение в if чего-то, чем надо пренебрегать - есть нежелание согласится с чем-то обычным. Таким-же как, если из одного города до другого надо доехать, то это потребует времени. Да, вместо велосипеда одно взять быструю машину но всё равно- какое-то время это потребуется. Очевидно.
В последнем примере опять-же тривиальный случай с типом string. А что делать, если функция возвращает другие типы данных? Например тот-же самый созданный файл, который не смог быть открытым, тк. места на плате нет или нет прав на создание. Что вы там за default value возьмёте?
Не понимаю. весь ассемблер набит функциями по переходу в зависимости от значения или состояния в аккумуляторе. Под это и создаётся оператор if, ну те. он потом с лёгкостью переводится в набор ассемблер команд.
Интересно было бы увидеть способы избавления от if в алгоритмах обработки изображений, ведь для GPU каждый if - это боль.
И ещё один момент но его задам с осторожностью. Могу ошибиться , тк. уже более 20 лет не живу в среде русского языка, но мне кажется, что ваше выражение
Помните, что операторы if — это далеко не все зло.
...должно подниматься так, что if операторы - уже зло. Но они не одни есть зло, есть и другие злые вещи. А я вам скажу своё мнение, что сам оператор не есть зло. Злом может быть необдуманное его использование, которое сильно усложняет читаемость кода, а также возведение этого оператора в своего рода ранг табу и после - "борьба" против его использования. Так называемая охота на ведьм.
Хорошая статья
Но если человек работает в б-м современной IDE, ему линтер все расскажет:) Другое дело, что многие это просто игнорируют, и это, собссно, одна из частей проблемы
пс Смешно смотреть, как народ не догоняет про абстрактность примеров и не может их экстраполировать:)
У код без ветвлений - это не абсолютное добро, он полезен в бизнес-логике, где данные и действия довольно абстрактные и их удобно читать (это ведь пост о поддержке кода?) без ветвлений. На уровне низкоуровневых действий код в ветвлениями полезней, сразу видно работу кода с примитивами и его реакцию на параметры.
Сам предпочитаю по возможности писать код в с тамим подходом и это, действительно, отдельное мастерство, иногда на читабельность приходится потратить столько же времени, сколько и на написание.
Но вот все эти примеры и советы в статье просто супер корявые. В них все проблемы захардкожены и решения даны именно для этого случая. Что это? Юнит-тесты?
В реальности все будет так:
Имя файла будет задано динамически (параметры запуска, конфиг) и if всё равно будет.
Наплодить десяток файлов вместо одного switch не всегда лучший выбор.
Что будет в переменной, то и передадим. Если null возможен, то проверка на него где-то будет так или иначе.
Вообще плохое решение. Выбор программистов-писателей. А дебажат и рефакторят пусть программисты-читатели.
Потенциально плохое решение, перенос бизнес-логики в несвязанный с нею код просто потому что "чтобы он не дублировался". Так можно вообще во все методы подобавлять параметр defaultValue...
Анти-if: недостающие паттерны