Рубрика "Виртуальные споры с Бугаенко")))
Егор любит провокативные посты, причём всегда (почти всегда?) в таких постах есть здравая мысль, заставляющая задуматься о том, как я пишу код. И этим они хороши)
Сейчас набрел на 2 поста о переменных:
https://www.yegor256.com/2015/01/12/compound-name-is-code-smell.html
https://www.yegor256.com/2015/09/01/redundant-variables-are-evil.html
Краткое содержание первого: составные имена переменных - типа flieName - это code smell. Аргумент - если имя пришлось сделать из 2+ слов, то это значит у нам слишком большая область видимости и нарушение Single Responsibility.
Тут в целом да. Я за небольшие методы, компилятор их оптимизирует. И такой критерий простоты метода как простые имена переменных - не очевидно, не единственный, но красиво.
А вот если говорить про имена полей класса, то тут скорее нет. Да, к классам тоже применим Single Responsibility, да, в имени поля не должно повторяться имя класса. Но видится, что строгое следование данному правилу усугубит "ООП-болезнь" - бесконечное дробление классов. А так мы отходим от структуры предметной области и усложняем чтение кода из-за прыжков между файлами. Вспомним, что разработка - искусство компромиссов)
Второй пост о том, что вынесение результата выполнения строчки кода в одноразовую локальную переменную - зло. Т.к. появляется 2+ строчки вместо одной, и ухудшается читаемость.
С одной стороны да. Но если у нас есть вызов метода, он уже достаточно сложный, а расчёт значений его параметров увеличивает длину строки кода до 100, 200... символов?
Да, можно выделить часть кода в отдельные методы. Методы тоже одноразовые...
А тогда какая разница?
Поэтому я бы сказал так: автоматом выносить все расчитываемые знпченич в переменные точно не надо.
Но и обратное не верно. Иногда такой приём улучшает читаемость, и в этом случае оправдан. Снова компромиссы)))
#clean_code #dev_compromises
Егор любит провокативные посты, причём всегда (почти всегда?) в таких постах есть здравая мысль, заставляющая задуматься о том, как я пишу код. И этим они хороши)
Сейчас набрел на 2 поста о переменных:
https://www.yegor256.com/2015/01/12/compound-name-is-code-smell.html
https://www.yegor256.com/2015/09/01/redundant-variables-are-evil.html
Краткое содержание первого: составные имена переменных - типа flieName - это code smell. Аргумент - если имя пришлось сделать из 2+ слов, то это значит у нам слишком большая область видимости и нарушение Single Responsibility.
Тут в целом да. Я за небольшие методы, компилятор их оптимизирует. И такой критерий простоты метода как простые имена переменных - не очевидно, не единственный, но красиво.
А вот если говорить про имена полей класса, то тут скорее нет. Да, к классам тоже применим Single Responsibility, да, в имени поля не должно повторяться имя класса. Но видится, что строгое следование данному правилу усугубит "ООП-болезнь" - бесконечное дробление классов. А так мы отходим от структуры предметной области и усложняем чтение кода из-за прыжков между файлами. Вспомним, что разработка - искусство компромиссов)
Второй пост о том, что вынесение результата выполнения строчки кода в одноразовую локальную переменную - зло. Т.к. появляется 2+ строчки вместо одной, и ухудшается читаемость.
С одной стороны да. Но если у нас есть вызов метода, он уже достаточно сложный, а расчёт значений его параметров увеличивает длину строки кода до 100, 200... символов?
Да, можно выделить часть кода в отдельные методы. Методы тоже одноразовые...
А тогда какая разница?
Поэтому я бы сказал так: автоматом выносить все расчитываемые знпченич в переменные точно не надо.
Но и обратное не верно. Иногда такой приём улучшает читаемость, и в этом случае оправдан. Снова компромиссы)))
#clean_code #dev_compromises
Yegor Bugayenko
A Compound Name Is a Code Smell
A variable name that consists of several words is a code smell because it indicates a variable scope that's too big.
Зоопарк консолей в Windows.
Пишу на примере Windows 11, но в 10-ке начиная с определенного билда все также.
1) Стандартная консоль Windows - теперь их стало две:
а) это связано с тем, что в Windows появился т.наз Windows Terminal. Это мультиоконная консоль, и при вызове cmd.exe вызывается именно именно. Но т.к. она мультиоконная - там же можно открыть любую другую консоль. Все в IDEA слизали)
б) а старая добрая однооконная консоль вызывается через conhost.exe. Зачем может пригодится старая консоль? Microsoft любят ломать совместимость, и новая консоль к примеру изменила API в плане скрытия окна консоли при старте программы.
2) Powershell - тоже использует Windows Terminal, и их стало даже три:
a) powershell.exe - это старая добрая синяя консоль (цвет значка остался синий, консоль по умолчанию черная), версия 5.х
б) pwsh.exe - новая черная консоль (я снова про цвет значка), версия 7.x. На данный момент ставится только руками. Ключевое замеченное мной отличие - есть API по считыванию данных в консоли, что удобно при работе AI агента, не надо выводить данные в лог.
в) conhost.exe powershell.exe - это способ запустить powershell в старом однооконном режиме
3) Git Bash - очень удобная штука, получаем консоль Linux с большим количеством утилит. Увы, не полный набор, а главное не хватает pacman - менеджера пакетов, который в свою очередь даст поставить все остальное. Еще важная особенность - там используются linux слэши и набор переменных среды хотя и наследуется, но отличается от Windows.
4) если утилит не хватает - можно поставить MSYS. Git Bash = урезанная версия MSYS без pacman + mingw64 (С-шный комполятор gcc в Windows)
5) еще можно поставить WSL - Windows Subsystem for Linux. Поверх нее работает Docker Desktop, а это значит не можно, а нужно ставить). В этом случае появляется еще консоль wsl.exe
В итоге у меня это выглядит как на картинке.
Но в целом получаем рабочую среду)
#win #dev
Пишу на примере Windows 11, но в 10-ке начиная с определенного билда все также.
1) Стандартная консоль Windows - теперь их стало две:
а) это связано с тем, что в Windows появился т.наз Windows Terminal. Это мультиоконная консоль, и при вызове cmd.exe вызывается именно именно. Но т.к. она мультиоконная - там же можно открыть любую другую консоль. Все в IDEA слизали)
б) а старая добрая однооконная консоль вызывается через conhost.exe. Зачем может пригодится старая консоль? Microsoft любят ломать совместимость, и новая консоль к примеру изменила API в плане скрытия окна консоли при старте программы.
2) Powershell - тоже использует Windows Terminal, и их стало даже три:
a) powershell.exe - это старая добрая синяя консоль (цвет значка остался синий, консоль по умолчанию черная), версия 5.х
б) pwsh.exe - новая черная консоль (я снова про цвет значка), версия 7.x. На данный момент ставится только руками. Ключевое замеченное мной отличие - есть API по считыванию данных в консоли, что удобно при работе AI агента, не надо выводить данные в лог.
в) conhost.exe powershell.exe - это способ запустить powershell в старом однооконном режиме
3) Git Bash - очень удобная штука, получаем консоль Linux с большим количеством утилит. Увы, не полный набор, а главное не хватает pacman - менеджера пакетов, который в свою очередь даст поставить все остальное. Еще важная особенность - там используются linux слэши и набор переменных среды хотя и наследуется, но отличается от Windows.
4) если утилит не хватает - можно поставить MSYS. Git Bash = урезанная версия MSYS без pacman + mingw64 (С-шный комполятор gcc в Windows)
5) еще можно поставить WSL - Windows Subsystem for Linux. Поверх нее работает Docker Desktop, а это значит не можно, а нужно ставить). В этом случае появляется еще консоль wsl.exe
В итоге у меня это выглядит как на картинке.
Но в целом получаем рабочую среду)
#win #dev
🤯2❤1
Отличие сеньора от джуна
Смотрел только что видео, где обсуждается, а точнее критикуется "Чистый код" Мартина.
Критика в отдельных местах справедливая, но в большинстве кажется критикой ради критики.
Т.е. из "Чистого кода" пытаются сделать Библию с заповедями, которые якобы нужно понимать буквально. А это очевидно не так.
Но не суть.
Понравилась одна фраза:
В реальных проектах всегда будет "говнокод", т.к. есть сроки. Ключевой момент в том, что сеньор всегда может аргументировано объяснить, почему он написал именно так, а джун - нет)
#memes #dev
Смотрел только что видео, где обсуждается, а точнее критикуется "Чистый код" Мартина.
Критика в отдельных местах справедливая, но в большинстве кажется критикой ради критики.
Т.е. из "Чистого кода" пытаются сделать Библию с заповедями, которые якобы нужно понимать буквально. А это очевидно не так.
Но не суть.
Понравилась одна фраза:
В реальных проектах всегда будет "говнокод", т.к. есть сроки. Ключевой момент в том, что сеньор всегда может аргументировано объяснить, почему он написал именно так, а джун - нет)
#memes #dev
👍3