Comments 26
Используйте утвердительные формулировки при именовании переменных. Названия переменных типа use_widget более удобны в работе, чем что-то вроде skip_widget, так как с их помощью можно избежать двойного отрицания.
Я тут ничего не понял. Не мог ли бы мне кто-нибудь объяснить, что он имел в виду?
use - да, используй (утвердительная формулировка)
skip - нет, не используй (отрицательная формулировка)
use_skip_widget
Что такое use и skip, понятно. Но чем плоха отрицательная формулировка skip_widget и причем тут двойное отрицание?
if (use_widget) {} если использовать
VS
if (!skip_widget) {} если не неиспользовать / если не пропускать
во втором случае лишняя когнитивная нагрузка
Да, в этом что-то есть
Тут тоже можно поспорить:
if (!use_widget) {
return;
}vs
if (skip_widget) {
return;
}
Skip, вообще говоря, не отрицание, хотя и означает отсутствие использования. Как по мне, особой когнитивной нагрузки не добавляет. Но уж если кому прям тяжело распарсить это выражение, можно добавить функцию типа
inline dont(bool flag) { return !flag; }
Получается вполне себе литературное dont(skip_widget).
Годный материал. Ссылки так вообще огонь! А нет ли таких же подходов к поиску информации и чтению документации? Например, я сталкивался с двумя крайностями при чтении документации.
Первое, когда документации на сотни или тысячи страниц и там сложно найти информацию. В этих случаях я пользовался поиском по тексту, поисковиком в интернете, опросами других программистов.
Второе когда документация выглядит так:
Функция вывод:
Выводит на экран.
Пример выдуманный. Обычно проблемы что-то вроде того, что нет указания на типы, библиотеки или нет информации о том как с этой функцией работать. Обычно я ищу примеры или информацию теми же способами.
Но должны быть какие-то другие способы. Я видел с какой скоростью некоторые люди ищут информацию, но к сожалению не имел возможности перенять их опыт, но очень бы хотел.
Если речь о поиске крупиц информации в большом объёме, тут помогает только интуиция, приходящая с опытом (нейронка учится по большому числу признаков фильтровать блоки текста, которые заслуживают большего внимания) плюс способность быстро переключать внимание — то самое клиповое мышление, хулимое великовозрастными снобами (которые сами нифига не умеют работать с такими объёмами информации).
И то, и другое приходит с практикой. Тяжело, мучительно, но со временем начинает нравиться, когда дофамин вырабатывается не от результата работы, а в предвкушении результата.
Бывают ситуации, когда надо просто засесть на неделю за какой‑то документ, впитать его целиком, отмечая про себя важные места и внутренние несостыковки, а потом с первого раза выдать оптимальное решение.
И это приходит с практикой. Ещё мучительнее, чем первый пункт, но и это со временем начинает нравиться.
Любая процедура или метод должны быть функцией, которая возвращает структуру с полями
Result:Bool;
ErrorCode:Int;
ErrorDescription:String;
Data:Object; - полезная нагрузка
ExecuteTime:Int;
Хороший подход для, например асинхронных сетевых вызовов, но зачем так жестить в любой процедуре/методе?
Ну в 80% процедур будут какие-то ошибки, которые надо обработать. Придумывать исключение под каждый случай - увольте. Ну и - быстрый выход вверх.
For Data in DataStream do
begin
executeResult := prepareData(Data);
if .Result = false thenexecuteResult
begin
Result := ;
exit;
end;
executeResult := compileData(Data);
if .Result = false thenexecuteResult
begin
Result := ;
exit;
end;
end;
Просто процитирую статью:
Люди, которые безапелляционно продвигают какой-либо подход, например
разработку через тестирование, как правило, оказываются правы в одних
ситуациях и неправы в других.
Видимо пейсмейкер это электрокардиостимулятор? Если это так, лучше заменить на пейсмейкер на кардиостимулятор.
Про негативные флаги - полностью согласен, лишняя когнитивка, но иногда нельзя завести позитивные флаги, которые должны быть включены по умолчанию, так как придется писать служебный код заполнения по дефолту. Ленивое.
Хорошие взгляды, основанные на практиках принятых в индустрии.
Насчет булевых переменных - важно разделять смысл использования. Если нам нужен признак вида "Да или НЕ да" - тогда булево, а если "Да, нет, не заполнено" - тогда перечисление
Для двух тоже имеет смысл. Особенно в коде который вы читаете.
# Типичный правильный вызов. Угадайте что True ?
run_code(True)
# Это тоже True, в большинастве языков
run_code(3)
# И это тоже True для Питона
run_code("False")
# Вызов с именем решает проблему, но не для всех языков
run_code(is_unsafe=True)
# Универсально для всех языков,
# статический анализ поможет не ошибиться
# Легко найти все небезовастные вызовы
run_code(Run.UNSAFE)
# Если аргументов много сложнее перепутать порядок
run_code(False, Run.UNSAFE, True)
Прежде чем тянуться к чему-то новому, лучше попытаться обойтись теми инструментами, которые уже у меня в распоряжении.
А как же прокачка своего резюме?
Мои взгляды на программирование на июль 2024 года