Сообщение Re: Именование нэймспэйсов от 03.10.2023 9:12
Изменено 03.10.2023 9:21 rg45
Re: Именование нэймспэйсов
Здравствуйте, Sm0ke, Вы писали:
S>Привет
S>помогите принять решение
S>пишу либу, которая состоит из разных частей
S>и вот думаю поместить каждую часть в свой отдельный namespace !
S>есть такое желание ...
S>пока оно всё лежит в одном большом namespace, к примеру назовём just::
S>и мне это не особо нравится
Я сам традиционно парюсь с подобными проблемами и пришел к тому, что переразбиение это так же плохо, как и недоразбиение. И руководствоваться при разбиении на подпространства лучше не объемами кода, а логическими связями между сущностями. Например(!), может оказаться, что есть смысл в выделении подпространства ui, но подпространства st и flags избыточны и лучше их не заводить.
S>Рассматриваю для начала два варианта:
S>Минусы:
S>* выглядит не очень (нагромождение resolution operators)
S>чтобы достучаться до типа это 3 штуки писать вместо двух (just::st::bla_bla вместо just::bla_bla)
Вот это как раз совсем не страшно, имхо. Если в каком-то конкретном месте использования такая запись и мелькнет пару раз, то код это сильно не нагрузит, зато сразу понятно что и откуда. А если в каком-то другом месте подобные конструкции мелькают слишком часто, то прямо там же пишешь "namespace st = just::st;" и дальше по коду пишешь просто "st::bla_bla", все просто, понятно и читабельно.
S>Привет
S>помогите принять решение
S>пишу либу, которая состоит из разных частей
S>и вот думаю поместить каждую часть в свой отдельный namespace !
S>есть такое желание ...
S>пока оно всё лежит в одном большом namespace, к примеру назовём just::
S>и мне это не особо нравится
Я сам традиционно парюсь с подобными проблемами и пришел к тому, что переразбиение это так же плохо, как и недоразбиение. И руководствоваться при разбиении на подпространства лучше не объемами кода, а логическими связями между сущностями. Например(!), может оказаться, что есть смысл в выделении подпространства ui, но подпространства st и flags избыточны и лучше их не заводить.
S>Рассматриваю для начала два варианта:
S>Минусы:
S>* выглядит не очень (нагромождение resolution operators)
S>чтобы достучаться до типа это 3 штуки писать вместо двух (just::st::bla_bla вместо just::bla_bla)
Вот это как раз совсем не страшно, имхо. Если в каком-то конкретном месте использования такая запись и мелькнет пару раз, то код это сильно не нагрузит, зато сразу понятно что и откуда. А если в каком-то другом месте подобные конструкции мелькают слишком часто, то прямо там же пишешь "namespace st = just::st;" и дальше по коду пишешь просто "st::bla_bla", все просто, понятно и читабельно.
Re: Именование нэймспэйсов
Здравствуйте, Sm0ke, Вы писали:
S>Привет
S>помогите принять решение
S>пишу либу, которая состоит из разных частей
S>и вот думаю поместить каждую часть в свой отдельный namespace !
S>есть такое желание ...
S>пока оно всё лежит в одном большом namespace, к примеру назовём just::
S>и мне это не особо нравится
Я сам традиционно парюсь с подобными проблемами и пришел к тому, что переразбиение это так же плохо, как и недоразбиение. И руководствоваться при разбиении на подпространства лучше не объемами кода, а логическими связями между сущностями. Например(!), может оказаться, что есть смысл в выделении подпространства ui, но подпространства st и flags избыточны и лучше их не заводить.
S>Минусы:
S>* выглядит не очень (нагромождение resolution operators)
S>чтобы достучаться до типа это 3 штуки писать вместо двух (just::st::bla_bla вместо just::bla_bla)
Вот это как раз совсем не страшно, имхо. Если в каком-то конкретном месте использования такая запись и мелькнет пару раз, то код это сильно не нагрузит, зато сразу понятно что и откуда. А если в каком-то другом месте подобные конструкции мелькают слишком часто, то прямо там же пишешь "namespace st = just::st;" и дальше по коду пишешь просто "st::bla_bla", все просто, понятно и читабельно.
S>Привет
S>помогите принять решение
S>пишу либу, которая состоит из разных частей
S>и вот думаю поместить каждую часть в свой отдельный namespace !
S>есть такое желание ...
S>пока оно всё лежит в одном большом namespace, к примеру назовём just::
S>и мне это не особо нравится
Я сам традиционно парюсь с подобными проблемами и пришел к тому, что переразбиение это так же плохо, как и недоразбиение. И руководствоваться при разбиении на подпространства лучше не объемами кода, а логическими связями между сущностями. Например(!), может оказаться, что есть смысл в выделении подпространства ui, но подпространства st и flags избыточны и лучше их не заводить.
S>Минусы:
S>* выглядит не очень (нагромождение resolution operators)
S>чтобы достучаться до типа это 3 штуки писать вместо двух (just::st::bla_bla вместо just::bla_bla)
Вот это как раз совсем не страшно, имхо. Если в каком-то конкретном месте использования такая запись и мелькнет пару раз, то код это сильно не нагрузит, зато сразу понятно что и откуда. А если в каком-то другом месте подобные конструкции мелькают слишком часто, то прямо там же пишешь "namespace st = just::st;" и дальше по коду пишешь просто "st::bla_bla", все просто, понятно и читабельно.