Якщо раніше я рекомендував уникати префіксів в назвах класів, то чимдалі переконуюся, що з цього треба робити саме правило. Я про оті всі ваші 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», а щось глибше, як-от «короткі назви всередині ліби — повні назви зовні».
Підозрюю, ця згубна звичка пішла з тих часів, коли мови програмування були значно примітивнішими, але вже майже чверть 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», а щось глибше, як-от «короткі назви всередині ліби — повні назви зовні».