Ох, ну ніхуя, Qt пофіксили баг (QTBUG-77428) про hoisting let та const в #QML, який я зарепортив три роки тому ⌛️

Взагалі сьогодні з шейдерами граюсь в #QML.

Конкретно цей я портував на Vulkanʼівський GLSL з чийогось коду і трохи адаптував під Qt Quick. Але багато ще треба зробити, аби його можна було легко використовувати.

Думаю додати можливість виставляти «світло» де завгодно, бо зараз воно до центру привʼязане. А ще, якщо прям трохи підчитати теорію кольорів, то колір тіні має залежати від обʼєкта, який її кидає.

Нахіба це? А шоб було!

Натрапив до речі сьогодні на отакий #QML Online https://stephenquan.github.io/qmlonline/, що на відміну KDEʼшного https://qmlonline.kde.org, по-перше, базується на Qt 6, а по-друге, дозволяє описати одразу декілька файлів. Але все одно лайно насправді. Хіба що щось швиденько перевірити треба.

Якщо раніше я рекомендував уникати префіксів в назвах класів, то чимдалі переконуюся, що з цього треба робити саме правило. Я про оті всі ваші vstring, CString, TString (хто памʼятає?), QString тощо, але не тільки про них.

Підозрюю, ця згубна звичка пішла з тих часів, коли мови програмування були значно примітивнішими, але вже майже чверть XXI сторіччя позаду, альо. Всі(?) використовувані в сучасному програмуванні мови мають засоби для скоупінгу імен на кшталт неймспейсів, кваліфікованих імпортів тощо.

Отже, на прикладі нашої поточної проги для мультимоніторного слайд-шоу (ну, що замовили…): є, значить, у нас модель дисплеїв, доступних в системі. Як вона називається? DisplayModel авжеж. Нормальна лаконічна та зрозуміла назва. Для цієї моделі є відповідна вьюшка, яка створює для кожного елементу моделі делегат. Вгадайте назви? DisplayView та DisplayDelegate, ага. Нє, ну а шо. Ще є DisplayInfo, DisplayIdentificationOverlay і тому подібне.

Мій перший ментор казав, що

якщо щось повторюється двічі, то варто було б вже замислитись, а якщо тричі — то обовʼязково треба якось узагальнювати.

Якщо мова про C++, то можна зробити namespace, і тоді в найгіршому випадку назви будуть: Display::Model, Display::View, Display::Delegate, тобто всього на два символи : більше — а в найкращому можна зробити по місцю використання using namespace Display, а далі просто писати Model, View та Delegate. Зазвичай в книжках не рекомендують писати using namespace, бо новачкам легко налажати, але при зваженому використанні це дуже корисна конструкція. Наш поточний підхід полягає в тому, що в cpp-файлі з реалізацією класу ми прям одразу пишемо using, або в деяких інших місцях в тій самій бібліотеці, але не в інших місцях використання. Іншими словами, якщо ти в контексті предметної області, то можна писати короткі імена, а якщо зовні — то повні.

В #QML того самого можна досягти за допомогою qualified imports. Наприклад, маючи модуль під назвою display, можна імпортувати його в глобальний скоуп імен через import display і писати всюди Model, View та Delegate, але QML трохи всратий в цьому плані, бо дозволяє… ммм… to shadow (затіняти?) імена з раніше імпортованих модулів і навіть не пише ворнінг. Тож краще одразу імпортувати як import display as Display або навіть import display as D, якщо надто впадлу, і тоді імена компонентів перетворюються на D.Model, D.View та D.Delegate відповідно.

Що маємо в результаті? По-перше, відсутні тавтологічні назви а ля Display::DisplayModel, в яких немає жодного сенсу, по-друге, потенційно писати менше, бо можна користуватися коротшими назвами доти, доки (по-третє) не буде конфліктів імен, які легко вирішуються повними назвами. Недоліки також є: треба трохи більше контролю за тим, що, де та як писати.

В ідеалі авжеж хотілося б мати тулзу, в яку можна зашити всі свої правила іменування та організації коду, причому не тупі банальності на кшталт «змінні з маленької, класи з великої» або «camelCase, а не snake_case», а щось глибше, як-от «короткі назви всередині ліби — повні назви зовні».