Go Clean Architecture
В go чатах я хейчу абсолютно все репозитории в названии которых есть что-то связанное с "Clean architecture", т.к. в них вижу ошибки. И меня просят скинуть такой репозиторий, где сделано нормально. И т.к. я такой репозиторий ни разу не находил, то когда-то давно решил делать свой.
Пока в планах сделать 2 репозитория:
1. Базовый. В нем будет минимум либ и минимум чего-то умного, а будет только верная работа с зависимостями и слоями
2. Навороченный. В котором будет все то же, что и в базовом, но и всякие свистелки, вроде грейсфул шатдауна и т.д.
Сейчас я делаю второй (навороченный), а потом его урежу до базового. Решил делать в этой последовательности т.к. базовый должен уметь трансформироваться в навороченный, путем добавления в него всего остального. Но если я сперва сделаю базовый, то могу что-то не учесть и он будет изначально сбивающим с толку.
Сейчас навороченный готов где-то на 60%. На мой взгляд в нем еще много что надо доделать, но в нем уже нет тех банальных ошибок, что есть в любых репозиториях, что я видел.
Главное, что сейчас хорошо - это структура проекта (ну кроме отсутствия слоя инфры, но это не сильно страшно пока, потом доделаю). Все зависимости в нужных направлениях идут. Все адаптеры с максимальным cohesion, нет coupling между чем-либо. Красота короче.
В планах еще будет написать что-то вроде FAQ. Где будут ответы на вопросы вроде: "А ГДЕ ПКГ" и т.д.
Вот Github (всё еще альфа версия!)
В go чатах я хейчу абсолютно все репозитории в названии которых есть что-то связанное с "Clean architecture", т.к. в них вижу ошибки. И меня просят скинуть такой репозиторий, где сделано нормально. И т.к. я такой репозиторий ни разу не находил, то когда-то давно решил делать свой.
Пока в планах сделать 2 репозитория:
1. Базовый. В нем будет минимум либ и минимум чего-то умного, а будет только верная работа с зависимостями и слоями
2. Навороченный. В котором будет все то же, что и в базовом, но и всякие свистелки, вроде грейсфул шатдауна и т.д.
Сейчас я делаю второй (навороченный), а потом его урежу до базового. Решил делать в этой последовательности т.к. базовый должен уметь трансформироваться в навороченный, путем добавления в него всего остального. Но если я сперва сделаю базовый, то могу что-то не учесть и он будет изначально сбивающим с толку.
Сейчас навороченный готов где-то на 60%. На мой взгляд в нем еще много что надо доделать, но в нем уже нет тех банальных ошибок, что есть в любых репозиториях, что я видел.
Главное, что сейчас хорошо - это структура проекта (ну кроме отсутствия слоя инфры, но это не сильно страшно пока, потом доделаю). Все зависимости в нужных направлениях идут. Все адаптеры с максимальным cohesion, нет coupling между чем-либо. Красота короче.
В планах еще будет написать что-то вроде FAQ. Где будут ответы на вопросы вроде: "А ГДЕ ПКГ" и т.д.
Вот Github (всё еще альфа версия!)
❤22🥴5👍2🤮2
Forwarded from Go Alive
Ну что же, по итогам голосования Homelander победил, и его лицо будет встречать читателя и сопровождать к образовательному материалу.
Статья об интерфейсах в Go опубликована на Хабре. Я постарался детально разобрать эту тему и надеюсь, что она будет полезной как для начинающих, так и для опытных гоферов. Приятного прочтения!
Статья об интерфейсах в Go опубликована на Хабре. Я постарался детально разобрать эту тему и надеюсь, что она будет полезной как для начинающих, так и для опытных гоферов. Приятного прочтения!
Хабр
Погружение в интерфейсы Go
Интерфейсы — одна из самых сложных тем для начинающих в Go. Я решил тщательно разобраться с этой темой и одновременно написать эту статью. После прочтения этой статьи вы сможете ответить на следующие...
👍6❤2🔥2🥴2
gofmt
Наткнулся на пост на реддите, и в нем фраза:
I have been professionally programming in Go since 2015. Our team has a codebase of beautiful, dense code written in a style of "one line is one idea".
И потом кусок кода:
и автор ищет какой-то форматтер, я не особо вник и начал сразу читать комментарии. Какое же было мое удивление, когда я понял, что фраза:
была не сарказмом...🚑
Наткнулся на пост на реддите, и в нем фраза:
I have been professionally programming in Go since 2015. Our team has a codebase of beautiful, dense code written in a style of "one line is one idea".
И потом кусок кода:
func Reload() error {
if !isStale() { return nil }
loadLock.Lock(); defer loadLock.Unlock()
info, err := GetInfo(); if err != nil { return fmt.Errorf("error retrieving info: %w", err) }
bs, err = ioutil.ReadFile(CONFIG_FILEPATH); if err != nil { return nil } // Use default
err = json.Unmarshal(bs, &config); if err != nil { return LogErr(err) }
err = something.UpdateFromConfig(info, config); if err != nil { return LogErr(err) }
return nil
}и автор ищет какой-то форматтер, я не особо вник и начал сразу читать комментарии. Какое же было мое удивление, когда я понял, что фраза:
a codebase of beautiful, dense code written in a style of "one line is one idea"
была не сарказмом...
Please open Telegram to view this post
VIEW IN TELEGRAM
😁10🤔1
Please open Telegram to view this post
VIEW IN TELEGRAM
💩9🔥5
This media is not supported in your browser
VIEW IN TELEGRAM
Генерация message коммитов с помощью ChatGPT api
Репозиторий:
https://github.com/Nutlope/aicommits
Установка и настройка:
1. Создаем тут api ключ и пополняем баланс. $10 должно хватить на очень долго т.к. модель 4o-mini
2. Выполняем
Использование:
Репозиторий:
https://github.com/Nutlope/aicommits
Установка и настройка:
1. Создаем тут api ключ и пополняем баланс. $10 должно хватить на очень долго т.к. модель 4o-mini
2. Выполняем
sudo npm install -g aicommits
aicommits config set OPENAI_KEY=replace_with_your_key
aicommits config set model=gpt-4o-mini
aicommits config set type=conventional
Использование:
git add .
aicommits
ENTRYPOINT и CMD в Docker
Если при запуске из терминала указать дополнительный параметр
1) При использовании entrypoint
он приаппендится к команде:
2) При использовании cmd
он заменит команду:
Можно использовать ENTRYPOINT и CMD например так:
тогда:
1) Если запустить так:
выполнится
2) а так:
выполнится
Если при запуске из терминала указать дополнительный параметр
docker run image_name 5
1) При использовании entrypoint
ENTRYPOINT ["sleep"]
он приаппендится к команде:
sleep 5
2) При использовании cmd
CMD ["sleep"]
он заменит команду:
5
Можно использовать ENTRYPOINT и CMD например так:
ENTRYPOINT ["sleep"]
CMD ["5"]
тогда:
1) Если запустить так:
docker run image_name
выполнится
sleep 5
2) а так:
docker run image_name 10
выполнится
sleep 10
👍11🔥4
Скачать видео с YouTube
Долго мучился, как скачать видео с ютуба. Видео качается или со звуком но в плохом качестве или в хорошем, но без звука (ютуб что-то поменял). А само скачивание очень медленное, если качать через всякие savefromnet.
Помогла утилита clipgrab
Скорость большая
Качает 4к со звуком
Долго мучился, как скачать видео с ютуба. Видео качается или со звуком но в плохом качестве или в хорошем, но без звука (ютуб что-то поменял). А само скачивание очень медленное, если качать через всякие savefromnet.
Помогла утилита clipgrab
sudo pacman -S clipgrab
Скорость большая
Качает 4к со звуком
👍8🔥1
Скачать видео с YouTube 2
В комментариях подсказали еще лучше способ:
https://github.com/yt-dlp/yt-dlp (94к звезд!)
Работает полностью из терминала
Поддерживает кроме ютуба еще много чего
Установка:
Запуск:
В комментариях подсказали еще лучше способ:
https://github.com/yt-dlp/yt-dlp (94к звезд!)
Работает полностью из терминала
Поддерживает кроме ютуба еще много чего
Установка:
sudo pacman -S yt-dlp
Запуск:
yt-dlp https://www.youtube.com/watch?v=Px_84vB-2ec
👍8❤3👌1
Хорошая статья про DIP
1. Из нее можно понять, что такое зависимость
2. Что такое сам принцип DIP
3. Почему интерфейсы располагаются в месте использования, а не реализации
https://habr.com/ru/articles/872078/
1. Из нее можно понять, что такое зависимость
2. Что такое сам принцип DIP
3. Почему интерфейсы располагаются в месте использования, а не реализации
https://habr.com/ru/articles/872078/
Хабр
90% разработчиков не понимают принцип инверсии зависимостей из SOLID. DIP — это не про абстракции
Зачастую, когда речь заходит про принцип инверсии зависимостей, можно услышать, что инверсия зависимостей (далее DIP) — это что-то там про зависимость от абстракций, и приводятся примеры, где в...
👍7
#книги
Лю Цисинь - Задача трех тел (трилогия)
15.07.2024 - 02.01.2025
Все ищу что-то, что мне понравится также, как Азимов)
В целом неплохо, книги серии вообще не похожи друг на друга, видно, как автор экспериментировал. Моментами было скучно, например, в первой какое-то долгое описание культурной революции в Китае. В третей один герой рассказывал сказки другому, они важные для сюжета, но такие долгие и неинтересные, что хотелось пропустить.
Только в третей книге началось то, что мне нравится больше всего - космос, корабли, физика и т.п. Во второй тоже было, но не так много.
Третья книга с интересными идеями, иногда даже гуглил разное, чтобы разобраться, но это совершенно необязательно для чтения книги, скорее просто книга рождала ассоциацию и я шел гуглить. Надеюсь, когда-нибудь прочитаю книги по физике, чтобы лучше понимать, как работает этот мир :)
Чтобы еще про космос найти..
Лю Цисинь - Задача трех тел (трилогия)
15.07.2024 - 02.01.2025
Все ищу что-то, что мне понравится также, как Азимов)
В целом неплохо, книги серии вообще не похожи друг на друга, видно, как автор экспериментировал. Моментами было скучно, например, в первой какое-то долгое описание культурной революции в Китае. В третей один герой рассказывал сказки другому, они важные для сюжета, но такие долгие и неинтересные, что хотелось пропустить.
Только в третей книге началось то, что мне нравится больше всего - космос, корабли, физика и т.п. Во второй тоже было, но не так много.
Третья книга с интересными идеями, иногда даже гуглил разное, чтобы разобраться, но это совершенно необязательно для чтения книги, скорее просто книга рождала ассоциацию и я шел гуглить. Надеюсь, когда-нибудь прочитаю книги по физике, чтобы лучше понимать, как работает этот мир :)
Чтобы еще про космос найти..
👍11🔥3
Forwarded from Cross Join - канал о разработке (Anton Okolelov)
🌐 HTTP QUERY: новый метод для поисковых запросов
В мире HTTP давно существует проблема с передачей сложных поисковых запросов. Когда разработчику нужно передать большой набор параметров для поиска или фильтрации, у него есть два не самых удачных варианта.
Можно использовать GET и передавать всё в URL:
Но URL дефакто имеет ограничения по длине, а кодирование сложных параметров становится громоздким.
Второй вариант — использовать POST и передавать параметры в теле запроса. Однако POST не предназначен для таких операций: он не кэшируется и не является идемпотентным, что усложняет работу с CDN и повторную отправку запросов.
Именно поэтому появился новый метод QUERY. Он позволяет отправлять поисковые параметры в теле запроса:
При этом QUERY сохраняет все преимущества GET: он безопасный, идемпотентный и кэшируемый. Cочетает поддержку тела запроса с возможностью кэширования.
Метод официально получил статус PROPOSED STANDARD, что означает скорое появление поддержки в браузерах и веб-фреймворках.
RFC: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/
В мире HTTP давно существует проблема с передачей сложных поисковых запросов. Когда разработчику нужно передать большой набор параметров для поиска или фильтрации, у него есть два не самых удачных варианта.
Можно использовать GET и передавать всё в URL:
GET /feed?q=foo&limit=10&sort=-published&filters[]=status:active&filters[]=type:post
Но URL дефакто имеет ограничения по длине, а кодирование сложных параметров становится громоздким.
Второй вариант — использовать POST и передавать параметры в теле запроса. Однако POST не предназначен для таких операций: он не кэшируется и не является идемпотентным, что усложняет работу с CDN и повторную отправку запросов.
Именно поэтому появился новый метод QUERY. Он позволяет отправлять поисковые параметры в теле запроса:
QUERY /feed
Content-Type: application/json
{
"q": "foo",
"limit": 10,
"sort": "-published",
"filters": ["status:active", "type:post"]
}
При этом QUERY сохраняет все преимущества GET: он безопасный, идемпотентный и кэшируемый. Cочетает поддержку тела запроса с возможностью кэширования.
Метод официально получил статус PROPOSED STANDARD, что означает скорое появление поддержки в браузерах и веб-фреймворках.
RFC: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/
👍23🔥8🤨1
#книги
Sam Newman - Building Microservices
02.01.2025 - 01.02.2025
Книга довольно поверхностная и скорее про общие идеи разработки, в том числе в микросервисах, а не про сами микросервисы. Конкретных деталей не так много, как хотелось бы. Когда я читал Chris Richardson - Microservices Patterns и у меня были к ней претензии, что ее можно было бы написать в лучших формулировках, и я думал, что Building Microservices будет как раз лучшей ее версией и больше про идеи, а не детали, но идеи оказались слишком общими и если выбирать книгу про микросервисы то сейчас я скажу, что это Microservices Patterns.
Не понравилась глава про Security. Хотя автор и сделал дисклеймер, что не является специалистом в этой области, всё равно создаётся впечатление, что тема раскрыта поверхностно. Зато понравились главы: Microservice Communication Styles и Scaling. Полезные и их можно прочитать даже в дополнение к Microservices Patterns, где глава, например, про сагу мне показалась слишком сложно сформулированной.
Каждая новая книга, которую я читаю, так или иначе пересекается с предыдущими, и это может влиять на степень моего интереса. Вероятно, это отразилось и на том, как мне читалась эта книга. Однако у нее и у книги Криса Ричардсона на Amazon и Goodreads примерно одинаковые рейтинги, так что, объективно, читатели оценивают их примерно одинаково.
Sam Newman - Building Microservices
02.01.2025 - 01.02.2025
Книга довольно поверхностная и скорее про общие идеи разработки, в том числе в микросервисах, а не про сами микросервисы. Конкретных деталей не так много, как хотелось бы. Когда я читал Chris Richardson - Microservices Patterns и у меня были к ней претензии, что ее можно было бы написать в лучших формулировках, и я думал, что Building Microservices будет как раз лучшей ее версией и больше про идеи, а не детали, но идеи оказались слишком общими и если выбирать книгу про микросервисы то сейчас я скажу, что это Microservices Patterns.
Не понравилась глава про Security. Хотя автор и сделал дисклеймер, что не является специалистом в этой области, всё равно создаётся впечатление, что тема раскрыта поверхностно. Зато понравились главы: Microservice Communication Styles и Scaling. Полезные и их можно прочитать даже в дополнение к Microservices Patterns, где глава, например, про сагу мне показалась слишком сложно сформулированной.
Каждая новая книга, которую я читаю, так или иначе пересекается с предыдущими, и это может влиять на степень моего интереса. Вероятно, это отразилось и на том, как мне читалась эта книга. Однако у нее и у книги Криса Ричардсона на Amazon и Goodreads примерно одинаковые рейтинги, так что, объективно, читатели оценивают их примерно одинаково.
🔥3👍1
Статья про НЕменеджерскую ветку развития разработчика
https://habr.com/ru/companies/kuper/articles/856224/
https://habr.com/ru/companies/kuper/articles/856224/
Хабр
Карьерный рост из senior: кто такой staff-инженер?
Привет! Меня зовут Дима Салахутдинов, я principal-инженер в Купере и автор tg-канала «Стафф-инженер» . У нас в компании это один из грейдов технической ветки развития инженеров, которую мы обобщенно...
Forwarded from Гомеостатическая Вселенная
Пока небольшой комментарий к новостям про то, что Майкрософт создали какой-то супер-пупер квантовый компьютер. Спойлер алерт: это все обман, чтобы набрать классы.
Но по порядку. Квантовые компьютеры делают из разных кубитов: некоторые используют сверхпроводящие микросхемы (как IBM и Google), некоторые — ионы (IonQ например), некоторые — фотоны (Xanadu). Ну и есть много других вариантов. Самая большая проблема с квантовыми компьютерами в том, что квантовая запутанность в них очень легко разрушается минимальным внешним воздействием. Поэтому эти комьютеры стараются изолировать от внешнего мира как можно лучше: засовывают в супер-криостаты, используют лучшие материалы и т.д.
Среди этих подходов выделяется один: топологические квантовые компьютеры. Точную работу описать довольно сложно, но попробую такую аналогию. Представьте, что у вас есть железная дорога типа Brio и вы можете катать по ней туда-сюда вагончики. А еще можете пересекать пути, делать мосты и т.д. Общая структура вашей дороги (как именно они пересекаются, сколько пересечений и между какими путям и т.д.) является ее топологией. В этих пересечениях реализуются вентили компьютера (т.е. логические операции). Так вот, внешний мир действует на вагончики: они то тормозят, то ускоряются, то вибрируют, то вообще пропадают. В обычном квантовом компьютере это является основной проблемой: квантовые состояния (вагончики) разрушаются, появляются ошибки. Но в топологическом квантовом компьютере операции зависят не от одиночкых вагончиков, а от общей структуры путей, а она остается постоянной и не подвержена влиянию внешнего мира (почти). Потенциально это очень мощный инструмент для реализации квантовых компьютеров, так как ему не страшен внешний мир.
На практике никто не знает, как именно это сделать. Вагончики должны быть очень специальными, чтобы реализовать такой компьютер. Это должны быть квазичастицы, которые называются анионы и обладают очень необычными свойствами. Они существуют в определенных двумерных материалах в определенных условиях (возможно). Майорановские фермионы, о которых вы слышали в новостях про Майкрософт — пример таких частиц.
Ура, введение готово, пора перейти к драме. Пока IBM и Google соревнуются за количество кубитов и пытаются как-то найти способ увеличить их до полезной величины, Microsoft пошли другим путем и пытаются создать топологический квнатовый компьютер. Если у них это получится, они обойдут всех на повороте и унесутся за горизонт. Но пока попытки, мягко говоря, не внушают доверия.
Из года в год они публикуют результаты про открытие и изучение этих самых Майорановских фермионов в самых престижных журналах. Из года в год в этих результатах находят ошибки, неверную статистику и прямой подлог и статьи отзываются (таких статей уже набралось не одна и не две, можно вот тут эпичный тред посмотреть). Т.к. это майкрософт, публиковать данные они отказываются (NDA и все такое) и верифицировать никак не получается. Но на каждой статье они собирают хайп, лайки и инвестиции — что еще нужно. Вот и нынешние "новости" — ровно из той же оперы. Те же авторы, один из рецензентов — главный автор прошлых отозванных статей, те же проблемы с данными и их доступностью, и т.д. Нет никаких оснований доверять этому. В целом, научное комьюнити давно уже крутит пальцем у виска, и главной загадкой остается вопрос, почему их вообще продолжают публиковать (хотя это и не загадка никакая, всем все понятно, кто за этим стоит).
В общем, не верьте хайпу! Я нарочно не даю ссылки на новости или статью, чтобы не разгонять этот хайп дальше. В целом, любые новости про квантовые компьютеры всегда можно делить на 10-100, но в особенности когда говорят про "прорыв, которого еще никогда не было". Это уж почти наверняка какая-то лажа.
Но по порядку. Квантовые компьютеры делают из разных кубитов: некоторые используют сверхпроводящие микросхемы (как IBM и Google), некоторые — ионы (IonQ например), некоторые — фотоны (Xanadu). Ну и есть много других вариантов. Самая большая проблема с квантовыми компьютерами в том, что квантовая запутанность в них очень легко разрушается минимальным внешним воздействием. Поэтому эти комьютеры стараются изолировать от внешнего мира как можно лучше: засовывают в супер-криостаты, используют лучшие материалы и т.д.
Среди этих подходов выделяется один: топологические квантовые компьютеры. Точную работу описать довольно сложно, но попробую такую аналогию. Представьте, что у вас есть железная дорога типа Brio и вы можете катать по ней туда-сюда вагончики. А еще можете пересекать пути, делать мосты и т.д. Общая структура вашей дороги (как именно они пересекаются, сколько пересечений и между какими путям и т.д.) является ее топологией. В этих пересечениях реализуются вентили компьютера (т.е. логические операции). Так вот, внешний мир действует на вагончики: они то тормозят, то ускоряются, то вибрируют, то вообще пропадают. В обычном квантовом компьютере это является основной проблемой: квантовые состояния (вагончики) разрушаются, появляются ошибки. Но в топологическом квантовом компьютере операции зависят не от одиночкых вагончиков, а от общей структуры путей, а она остается постоянной и не подвержена влиянию внешнего мира (почти). Потенциально это очень мощный инструмент для реализации квантовых компьютеров, так как ему не страшен внешний мир.
На практике никто не знает, как именно это сделать. Вагончики должны быть очень специальными, чтобы реализовать такой компьютер. Это должны быть квазичастицы, которые называются анионы и обладают очень необычными свойствами. Они существуют в определенных двумерных материалах в определенных условиях (возможно). Майорановские фермионы, о которых вы слышали в новостях про Майкрософт — пример таких частиц.
Ура, введение готово, пора перейти к драме. Пока IBM и Google соревнуются за количество кубитов и пытаются как-то найти способ увеличить их до полезной величины, Microsoft пошли другим путем и пытаются создать топологический квнатовый компьютер. Если у них это получится, они обойдут всех на повороте и унесутся за горизонт. Но пока попытки, мягко говоря, не внушают доверия.
Из года в год они публикуют результаты про открытие и изучение этих самых Майорановских фермионов в самых престижных журналах. Из года в год в этих результатах находят ошибки, неверную статистику и прямой подлог и статьи отзываются (таких статей уже набралось не одна и не две, можно вот тут эпичный тред посмотреть). Т.к. это майкрософт, публиковать данные они отказываются (NDA и все такое) и верифицировать никак не получается. Но на каждой статье они собирают хайп, лайки и инвестиции — что еще нужно. Вот и нынешние "новости" — ровно из той же оперы. Те же авторы, один из рецензентов — главный автор прошлых отозванных статей, те же проблемы с данными и их доступностью, и т.д. Нет никаких оснований доверять этому. В целом, научное комьюнити давно уже крутит пальцем у виска, и главной загадкой остается вопрос, почему их вообще продолжают публиковать (хотя это и не загадка никакая, всем все понятно, кто за этим стоит).
В общем, не верьте хайпу! Я нарочно не даю ссылки на новости или статью, чтобы не разгонять этот хайп дальше. В целом, любые новости про квантовые компьютеры всегда можно делить на 10-100, но в особенности когда говорят про "прорыв, которого еще никогда не было". Это уж почти наверняка какая-то лажа.
👍7😱2
Почему в го "приняты" имена пакетов в одно слово и однобуквенные названия переменных
Судя по всему причина для этого - личные предпочтения Rob Pike, которые он описывает в своей заметке Notes on Programming in C от 1989г.
Мне нравится мысль, что длина имени переменной зависит от скоупа её использования. То есть, чем в большем числе мест используется переменная, тем более обоснованно ее длинное имя и наоборот, если это обычный цикл на пару строк, то имя должно быть короче.
Пайк тоже говорит об этом и приводит в пример цикл, где индекс обозначется буквой i. Как по мне это сразу некое исключение, ибо я бы назвал переменную i даже в большом цикле т.к. это устойчивое обозначение индекса в математике. И поэтому после i идет j, а потом k.
Дальше Пайк говорит, что ему больше нравится maxphysaddr, а не MaximumPhysicalAddress и причины для этого:
1. Второе название дольше печатать (Неактуально для современных редакторов кода)
2. Затрудняет восприятие вычислений (Вычислений в Си может быть и то спорно, но не энтерпрайзного кода точно)
3. Цитата: "Я избегаю встроенных заглавных букв в именах; для моего глаза, привыкшего к текстам, они слишком неудобны для чтения. Они режут взгляд." (Определение слова "вкусовщина")
Видимо поэтому мы имеем рекомендацию в го делать имена пакетов в одно слово, а не CamelCase или snake_case.
Возможно пакет с названием "strconv" еще читаем, но всякие veryimportantdocumentuploader - нет.
Также Пайку больше нравится название переменной np, а не NodePointer. И в целом это может быть нормально в приложении вся суть которого крутится вокруг связного списка или внутри либы для его реализации, но в чем-то большем это создаст трудности.
Мысль, с который я 100% согласен - если переменная названа maxphysaddr не называйте её «соседа» lowestaddress. То есть консистентность должна быть.
В общем, после этой заметки мне будет легче не винить себя за то, что не пишу названия пакетов в го в одно слово т.к. хочу получить что-то более читаемое.
Про такие темы принято говорить, что это "вкусовщина", что от части так, но всё же не надо оправдывать этим словом отсутствие дисциплины. А чтобы посмотреть какие-то аргументированные мнения есть отличная книга Стива МакКоннелла - Совершенный Код (2004). Она конечно не самая новая и некоторые примеры будут неактуальны сегодня, но многие подходы применимы. Моя "вкусовщина" основана по большей части на этой книге.
Судя по всему причина для этого - личные предпочтения Rob Pike, которые он описывает в своей заметке Notes on Programming in C от 1989г.
Мне нравится мысль, что длина имени переменной зависит от скоупа её использования. То есть, чем в большем числе мест используется переменная, тем более обоснованно ее длинное имя и наоборот, если это обычный цикл на пару строк, то имя должно быть короче.
Пайк тоже говорит об этом и приводит в пример цикл, где индекс обозначется буквой i. Как по мне это сразу некое исключение, ибо я бы назвал переменную i даже в большом цикле т.к. это устойчивое обозначение индекса в математике. И поэтому после i идет j, а потом k.
Дальше Пайк говорит, что ему больше нравится maxphysaddr, а не MaximumPhysicalAddress и причины для этого:
1. Второе название дольше печатать (Неактуально для современных редакторов кода)
2. Затрудняет восприятие вычислений (Вычислений в Си может быть и то спорно, но не энтерпрайзного кода точно)
3. Цитата: "Я избегаю встроенных заглавных букв в именах; для моего глаза, привыкшего к текстам, они слишком неудобны для чтения. Они режут взгляд." (Определение слова "вкусовщина")
Видимо поэтому мы имеем рекомендацию в го делать имена пакетов в одно слово, а не CamelCase или snake_case.
Возможно пакет с названием "strconv" еще читаем, но всякие veryimportantdocumentuploader - нет.
Также Пайку больше нравится название переменной np, а не NodePointer. И в целом это может быть нормально в приложении вся суть которого крутится вокруг связного списка или внутри либы для его реализации, но в чем-то большем это создаст трудности.
Мысль, с который я 100% согласен - если переменная названа maxphysaddr не называйте её «соседа» lowestaddress. То есть консистентность должна быть.
В общем, после этой заметки мне будет легче не винить себя за то, что не пишу названия пакетов в го в одно слово т.к. хочу получить что-то более читаемое.
Про такие темы принято говорить, что это "вкусовщина", что от части так, но всё же не надо оправдывать этим словом отсутствие дисциплины. А чтобы посмотреть какие-то аргументированные мнения есть отличная книга Стива МакКоннелла - Совершенный Код (2004). Она конечно не самая новая и некоторые примеры будут неактуальны сегодня, но многие подходы применимы. Моя "вкусовщина" основана по большей части на этой книге.
👍21❤3🔥2