Мои взгляды на программирование на июль 2024 года

[FlyingDutchman2]

Используйте утвердительные формулировки при именовании переменных. Названия переменных типа use_widget более удобны в работе, чем что-то вроде skip_widget, так как с их помощью можно избежать двойного отрицания.

Я тут ничего не понял. Не мог ли бы мне кто-нибудь объяснить, что он имел в виду?

[economist75]

use - да, используй (утвердительная формулировка)
skip - нет, не используй (отрицательная формулировка)

[0Bannon]

use_skip_widget

[delphinpro]

я здесь читаю как "Использовать виджет с названием 'skip'"

[vladshulkevich]

use_skiped_widget

[FlyingDutchman2]

Что такое use и skip, понятно. Но чем плоха отрицательная формулировка skip_widget и причем тут двойное отрицание?

[delphinpro]

if (use_widget) {} если использовать
VS
if (!skip_widget) {} если не неиспользовать / если не пропускать

во втором случае лишняя когнитивная нагрузка

[FlyingDutchman2]

Да, в этом что-то есть

[amphasis]

Тут тоже можно поспорить:

if (!use_widget) {
  return;
}

vs

if (skip_widget) {
  return;
}

[delphinpro]

в этом случае читается одинаково:
если не использовать
VS
если не использовать / если пропустить

Нет двойного отрицания

[yappari]

Skip, вообще говоря, не отрицание, хотя и означает отсутствие использования. Как по мне, особой когнитивной нагрузки не добавляет. Но уж если кому прям тяжело распарсить это выражение, можно добавить функцию типа

inline dont(bool flag) { return !flag; }

Получается вполне себе литературное dont(skip_widget).

[delphinpro]

дело же не только в этой переменной. полно и других примеров
enabled_plugin / disabled_plugin например. !disabled_plugin - двойное отрицание - "не неактивный плагин"

[piton369]

Годный материал. Ссылки так вообще огонь! А нет ли таких же подходов к поиску информации и чтению документации? Например, я сталкивался с двумя крайностями при чтении документации.

Первое, когда документации на сотни или тысячи страниц и там сложно найти информацию. В этих случаях я пользовался поиском по тексту, поисковиком в интернете, опросами других программистов.

Второе когда документация выглядит так:
Функция вывод:
Выводит на экран.

Пример выдуманный. Обычно проблемы что-то вроде того, что нет указания на типы, библиотеки или нет информации о том как с этой функцией работать. Обычно я ищу примеры или информацию теми же способами.

Но должны быть какие-то другие способы. Я видел с какой скоростью некоторые люди ищут информацию, но к сожалению не имел возможности перенять их опыт, но очень бы хотел.

[Fedorkov]

Если речь о поиске крупиц информации в большом объёме, тут помогает только интуиция, приходящая с опытом (нейронка учится по большому числу признаков фильтровать блоки текста, которые заслуживают большего внимания) плюс способность быстро переключать внимание — то самое клиповое мышление, хулимое великовозрастными снобами (которые сами нифига не умеют работать с такими объёмами информации).

И то, и другое приходит с практикой. Тяжело, мучительно, но со временем начинает нравиться, когда дофамин вырабатывается не от результата работы, а в предвкушении результата.

Бывают ситуации, когда надо просто засесть на неделю за какой‑то документ, впитать его целиком, отмечая про себя важные места и внутренние несостыковки, а потом с первого раза выдать оптимальное решение.

И это приходит с практикой. Ещё мучительнее, чем первый пункт, но и это со временем начинает нравиться.

[HADGEHOGs]

Любая процедура или метод должны быть функцией, которая возвращает структуру с полями

Result:Bool;

ErrorCode:Int;

ErrorDescription:String;

Data:Object; - полезная нагрузка

ExecuteTime:Int;

[FlyGst]

Хороший подход для, например асинхронных сетевых вызовов, но зачем так жестить в любой процедуре/методе?

[HADGEHOGs]

Ну в 80% процедур будут какие-то ошибки, которые надо обработать. Придумывать исключение под каждый случай - увольте. Ну и - быстрый выход вверх.

For Data in DataStream do
begin


executeResult := prepareData(Data);
if executeResult.Result = false then
begin
Result := executeResult;
exit;
end;


executeResult := compileData(Data);
if executeResult.Result = false then
begin
Result := executeResult;
exit;
end;


end;

[Fedorkov]

Большинство ошибок нужно не обрабатывать, а пробрасывать в вызывающий код в неизменном виде. Именно для этого придумали исключения.

[Andrey_Solomatin]

Просто процитирую статью:

Люди, которые безапелляционно продвигают какой-либо подход, например
разработку через тестирование, как правило, оказываются правы в одних
ситуациях и неправы в других.

[oufucom]

Видимо пейсмейкер это электрокардиостимулятор? Если это так, лучше заменить на пейсмейкер на кардиостимулятор.

[ivanovichvasiliy]

Про негативные флаги - полностью согласен, лишняя когнитивка, но иногда нельзя завести позитивные флаги, которые должны быть включены по умолчанию, так как придется писать служебный код заполнения по дефолту. Ленивое.

[Andrey_Solomatin]

Хорошие взгляды, основанные на практиках принятых в индустрии.

[killyself]

Насчет булевых переменных - важно разделять смысл использования. Если нам нужен признак вида "Да или НЕ да" - тогда булево, а если "Да, нет, не заполнено" - тогда перечисление

[Andrey_Solomatin]

Для двух тоже имеет смысл. Особенно в коде который вы читаете.

# Типичный правильный вызов.  Угадайте что 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)

[killyself]

Да, конечно, для аргументов функций замена флага на перечисление зачастую хорошее решение, я говорил скорее про переменные, которые видны в скоупе, и не требуют дополнительных действий для понимания назначения

[tolyanski]

Прежде чем тянуться к чему-то новому, лучше попытаться обойтись теми инструментами, которые уже у меня в распоряжении.

А как же прокачка своего резюме?