LINUX.ORG.RU

[c++] Префиксы у классов, переменных и т.п.


0

0

Иногда вижу префиксы m у перменных (mSomeVar) и I (большая i) у классов (ISomeClass). Насколько я понимаю, второе говорит о том, что класс является интерфейсом. А что есть m?

Какие ещё бывают префиксы?

Если у меня проект графического редактора на Qt, у которого есть поле, область инструментов, линейки масштаба, палитра и т.п., следует ли давать всем этим виджетам какой-то префикс?

Спасибо.

★★★★★

> А что есть m?

поле класса

lester ★★★★ ()

> следует ли давать всем этим виджетам какой-то префикс?

Помести их в отдельный namespace

anonymous ()
Ответ на: комментарий от anonymous

Внутри класса что-ли?

Господи, а это-то зачем?

Удобнее, чтобы отличать члены от нечленов.

anonymous ()
Ответ на: комментарий от anonymous

> Помести их в отдельный namespace

здравая мысль. теперь нужность пространств имён стала яснее ясного :)

Obey-Kun ★★★★★ ()
Ответ на: комментарий от anonymous

> Внутри класса что-ли?

При чем здесь это? Имеет, допустим, виджет QFrostDrawArea и QFrostRectangle. И ещё кучу подобного. Как говорит товарищ, вместо такой гадости лучше использовать что-то вроде qfrost::DrawArea и qfrost::Rectangle.

Obey-Kun ★★★★★ ()
Ответ на: комментарий от lester

> поле класса

поле класса = переменная-член класса? в общем-то тоже здравая идея... а как правильно — mSomeStuff или m_someStuff?

Obey-Kun ★★★★★ ()
Ответ на: комментарий от Obey-Kun

> вместо такой гадости лучше использовать что-то вроде qfrost::DrawArea и qfrost::Rectangle.

и что - будешь везде писать «qfrost::Rectangle»? или using namespace расставлять и при просмотра кода свято верить, что Rectangle именно твой, а не из Carbon, FLTK и т.д.?

lester ★★★★ ()
Ответ на: комментарий от Obey-Kun

> а как правильно — mSomeStuff или m_someStuff?

я использую первый вариант, а «правильного» тут нет - есть общий стиль у проекта, вот его лучше и придерживаться ( хотя есть любители писать t_lVar, inParam и т.п. - это уже извращение )

lester ★★★★ ()
Ответ на: комментарий от lester

и что - будешь везде писать «qfrost::Rectangle»? или using namespace расставлять и при просмотра кода свято верить, что Rectangle именно твой, а не из Carbon, FLTK и т.д.?

При именовании переменных в camelCase или c_style, а не CamelCase таких проблем не возникает (путаницы переменная/тип). А для разделения типов пространства имён и предназначены и если кто-то использует using namespace на большие куски кода то он ССЗБ.

Begemoth ★★★★★ ()
Ответ на: комментарий от lester

>и что - будешь везде писать «qfrost::Rectangle»? или using namespace расставлять и при просмотра кода свято верить, что Rectangle именно твой, а не из Carbon, FLTK и т.д.?

Оно явно не хуже чем QFrostRectangle, да и нормальный текстовый редактор умеет автодополнять.

anonymous ()
Ответ на: комментарий от lester

хотя есть любители писать t_lVar, inParam и т.п. - это уже извращение

ну тогда надо ещё вспомнить стиль именвания структур в Windows API - SOMEVERYUSEFULSTRUCTUREWITHMAMNYMANYFIELDS

Begemoth ★★★★★ ()
Ответ на: комментарий от lester

using namespace qfrost, далее Rectangle.

Аналогично сделано, например, в libtorrent. Ну таки да, Rectangle не лучшее название. Хотя в голову что-то не менее лаконичное, но более конкретное в голову не приходит. Может, придумаешь? Это виджет для описания элементарной ячейки модели. После придания ему некоторых физических параметров, он становится qfmath::InternalCell (qfmath — пространство имён для «математического ядра» программы).

Obey-Kun ★★★★★ ()
Ответ на: комментарий от Begemoth

> При именовании переменных в camelCase или c_style, а не CamelCase таких проблем не возникает (путаницы переменная/тип)

у меня как раз классы CamelCase, а переменные camelCase.

А для разделения типов пространства имён и предназначены и если кто-то использует using namespace на большие куски кода то он ССЗБ.

учту

хотелось бы равняться на стиль KDE libs, там как, кто-нибудь знает? :)

Obey-Kun ★★★★★ ()
Ответ на: комментарий от Begemoth

> А для разделения типов пространства имён и предназначены

но читабельности они не добавляют, в тоже время префикс 'Q', например, сразу говорит про происхождение класса и при этом не раздувает код

lester ★★★★ ()
Ответ на: комментарий от lester

> ( хотя есть любители писать t_lVar, inParam и т.п. - это уже извращение )

у меня все функции выглядят как SomeFunct(Foo inParam1, Bar inParam2). Если далее идёт что-то вроде mParam1=inParam1; mParam2=inParam2, то разве это не оправдано?

Obey-Kun ★★★★★ ()
Ответ на: комментарий от lester

но читабельности они не добавляют, в тоже время префикс 'Q', например, сразу говорит про происхождение класса и при этом не раздувает код

Ну, это частный случай короткого префикса. А при использовании пространств имён им можно псевдонимы namespace a = aaaaaaaa; и вместо aaaaaaaa использовать a.

Begemoth ★★★★★ ()

Это ж венгерская нотация (hungarian notaion). m - это от member

Умоляю, не используйте.

dmitry_vk ★★★ ()
Ответ на: комментарий от dmitry_vk

это системная венгерская нотация. умоляю, научитесь уже отличать одно от другого

jtootf ★★★★★ ()
Ответ на: комментарий от dmitry_vk

«Венгерская Нотация была изобретена программистом Microsoft Чарльзом Симони (Charles Simonyi). Одним из главных проектов, над которым работал Симони в Microsoft, был Word; фактически он вел проект по созданию первого в мире текстового редактора, работающего в режиме WYSIWYG, того, что в Xerox Parc называли Bravo. … Оригинальная концепция Венгерской Нотации Симони была названа в Microsoft Венгерской для Приложений (Apps Hungarian), потому что использовалась она в Подразделении Приложений (Applications Division), которое, в частности, разрабатывало Word и Excel. В исходном тексте Excel вы увидите много rw и col, и когда вы их увидите, вы сразу поймете, что они относятся к строкам и колонкам. Да, они оба целые, но никогда не имеет смысла присваивать значение одного другому. В Word, как мне говорили, вы увидите много xl и xw, где xl означает «горизонтальная координата относительно листа», и xw означает «горизонтальная координата относительно окна». Оба целые. Не взаимозаменяемые. В обоих приложениях вы увидите много cb, означающего „счетчик байтов.“ Да, это тоже целое, но вы можете узнать об этом много больше, только посмотрев на имя переменной. Это счетчик байтов: размер буфера. И если вы видите xl = cb, ну, в общем, слышите Свисток Плохого Кода, который говорит, что здесь код несомненно является неправильным, потому что даже при том, что и xl, и cb являются целыми, полный идиотизм присваивать размер буфера горизонтальной координате. … Венгерская для Приложений была чрезвычайно ценна, особенно в эпоху программирования на C, в котором компилятор не предоставлял очень полезную систему пользовательских типов.

Но затем случилось нечто ужасное.

Наступили черные дни для Венгерской Нотации.

Никто, кажется, не знает, почему или как, но кажется, что именно авторы документации из команды Windows неосторожно изобрели то, что стало известным как Системная Венгерская.

Кто-то где-то прочитал статью Симони, где он использовал слово „тип“, и решил, что тот использовал тип, как класс, как языке с системой пользовательских типов, как проверку типов, которую делает компилятор. Он не это имел в виду. Он тщательно и точно объяснил, что подразумевал словом под словом „тип“, но это не помогло. Вред был нанесен.

Венгерская для приложений была очень полезна, были определены конкретные приставки, такие как „ix“ для обозначения индекса в массиве, „c“ для счетчиков, „d“ для разницы между двумя числами (например, „dx“ означал „ширину“), и т.д.

Системная Венгерская имела намного менее полезные приставки, такие как „l“ для длинного целого (long), „ul“ для беззнакового длинного целого (unsigned long), и „dw“ для двойного слова (double word), которое, фактически, мм, является беззнаковым длинным целым. В Системной Венгерской единственной вещью, о которой говорил вам префикс, фактически был только тип данной переменной.

Это было незаметным, но абсолютно полным противоречием намерениям и практике Симони, и это показывает вам, что если вы пишете замысловатую, сухую академическую прозу, никто ее не поймет, ваши идеи будут извращены, и затем эти извращенные идеи будут высмеяны, даже несмотря на то, что они никогда не были вашими идеями. Так, на Системном Венгерском имя переменной dwFoo говорило вам, черт побери, только то, что это foo имеет размерность в двойное слово, что, в общем, не говорит вам вообще ничего полезного. Таким образом, неудивительно, что люди восстали против Системной Венгерской. „

Obey-Kun ★★★★★ ()
Ответ на: комментарий от anonymous

> Удобнее, чтобы отличать члены от нечленов.

Члены от не членов прекрасно отличает ctags и К°.

Открытые члены класса, все как один на букву 'm' - выглядит душераздирающе...

LamerOk ★★★★★ ()
Ответ на: комментарий от Obey-Kun

у меня все функции выглядят как SomeFunct(Foo inParam1, Bar inParam2). Если далее идёт что-то вроде mParam1=inParam1; mParam2=inParam2, то разве это не оправдано?

Нет, это не оправдано и выглядит кошмарно.

Идоматическая конструкция для такой фигни:

SomeFunct(Foo param1, Bar param2)
{
    this.param1 = param1;
    this.param2 = param2;
}

Какбэ у тебя уже есть прекрасный халявный префикс для доступа к переменным класса, и можно легко обойтись без всякого идиотизма.

Алсо, 'this' помогает в длинных простынях методов, если вдруг.

Еще есть религиозное движение, призывающие использовать 'this' всегда, но я в нем не состою.

LamerOk ★★★★★ ()
Ответ на: комментарий от LamerOk

> Открытые члены класса, все как один на букву 'm' - выглядит душераздирающе...

у моих классов открытых переменных-членов как правило нет. если только это не c-way структура без функций.

Obey-Kun ★★★★★ ()
Ответ на: комментарий от LamerOk

> Открытые члены класса, все как один на букву 'm' - выглядит душераздирающе...

я их вообще выношу из публичного класса в приватный, чтоб народ не смущать, а душераздирающе смотрятся поля, которые ничем не отличимы от локальных переменных да еще и названы одной буквой - приходится глазами бегать, чтоб проверить - ага в списке параметров и среди локальных переменных этого имени нет, значит это поле( или вообще глобальная переменная - хз )

lester ★★★★ ()
Ответ на: комментарий от LamerOk

> Алсо, 'this' помогает в длинных простынях методов, если вдруг.

Да, код неплохо выглядит. Наверное, переделаю всё в такой вид.

Obey-Kun ★★★★★ ()
Ответ на: комментарий от Obey-Kun

> у моих классов открытых переменных-членов как правило нет

Так начерта тебе вообще тогда префикс? Отличить член класса от автоматических переменных в теле его метода? Ипать-колотить, это ж сколько переменных должно быть в области видимости метода, чтоб возникла такая потребность?

LamerOk ★★★★★ ()
Ответ на: комментарий от lester

> поля, которые ничем не отличимы от локальных переменных да еще и названы одной буквой

Если эти буквы не 'x' и 'y', или подобные им, то всё равно код надо рефакторить как-то.

«Безымянные» поля - это уже полный п-ц.

LamerOk ★★★★★ ()
Ответ на: комментарий от LamerOk

Отличить от входных переменных метода, например. Приводил же пример выше. Вот ещё один, копипаста из кода:

InternalCell::InternalCell(std::vector<double> &inDimensions,
                           double &inTemperature, double &inMeltedPart,
                           Phased &inCapacity, Phased &inConductivity,
                           double &inTransitionTemperature,
                           double &inTransitionHeat
                           )
{

    dimensions = inDimensions;
    temperature = inTemperature;
    thawedPart = inMeltedPart;
    capacity = inCapacity;
    conductivity = inConductivity;
    transitionTemperature = inTransitionTemperature;
    transitionHeat = inTransitionHeat;
    CalcEnthalpy();
    CalcInversedEffectiveConductivity();
}
Obey-Kun ★★★★★ ()
Ответ на: комментарий от Obey-Kun

1. пакуй все в структуру
2. «double &inTemperature» - а 'const' Пушкен писать будет

lester ★★★★ ()
Ответ на: комментарий от Obey-Kun

1. Двачую Лестера.

2.

Отличить от входных переменных метода, например.


Это уже см. выше. Я вопрошал про ситуацию чуть менее очевидную.

LamerOk ★★★★★ ()
Ответ на: комментарий от lester

Типа «сэкономить» на загрузке параметров в стэк.

LamerOk ★★★★★ ()
Ответ на: комментарий от Obey-Kun

Re: inParam

дополню код от LamerOk - мне так больше по душе:

SomeFunct(const Foo& param1, const Bar& param2) 
{ 
    this.param1 = param1; 
    this.param2 = param2; 
}
necromant ()
Ответ на: Re: inParam от necromant

Согласился бы, если бы относительно параметров было бы всегда верно следующее утверждение:

sizeof(T*) <= sizeof(T)

LamerOk ★★★★★ ()
Ответ на: комментарий от Obey-Kun

>у меня все функции выглядят как SomeFunct(Foo inParam1, Bar inParam2).

Я бы на твоём месте называл функции не в CamelCase, чтобы с классами не путать. Например lowerCamel.

anonymous ()
Ответ на: комментарий от anonymous

Функции и классы в CamelCase, переменные в camelCase. Так в огромном количестве проектов принято. И это как укуриться надо, чтобы класс с функцией перепутать. А вот функцию с переменной — легко.

Obey-Kun ★★★★★ ()
Ответ на: комментарий от lester

> 1. пакуй все в структуру

так и будет, когда оно понадобится

2. «double &inTemperature» - а 'const' Пушкен писать будет

точняк :)

& я использую, чтоб лишний раз не копировать переменную. Типа быстрее.

Obey-Kun ★★★★★ ()
Ответ на: комментарий от LamerOk

> sizeof(T*) <= sizeof(T)

Блин, я дурак. Ссылка на что угодно это ведь 8 байт для 64-разрядной системы и 4 байта для 32-разрядной, верно?

Obey-Kun ★★★★★ ()
Ответ на: комментарий от Obey-Kun

> & я использую, чтоб лишний раз не копировать переменную. Типа быстрее.

для double это не имеет никакого смысла

lester ★★★★ ()
Ответ на: комментарий от LamerOk

> На 32-ух битах? О_о

на них самых - можешь быстро набить пример и проверить

lester ★★★★ ()
Ответ на: комментарий от lester

Что проверить? Что sizeof(double) > sizeof(double*)? Я и так это знаю. :3

LamerOk ★★★★★ ()
Ответ на: комментарий от lester

И как ты предлагаешь проверить скорость одних и тех же опкодов на разных камнях? :3

LamerOk ★★★★★ ()
Ответ на: комментарий от lester

я в конец запутался.

Короче, что вызывается быстрее: SomeFunct(double& x) или SomeFunct(double x)? SomeFunct2(MyStruct& x) или SomeFunct2(MyStruct x), где MyStruct содержит три дабла. Когда стоит переходить с передачи значения на использование ссылки?

Obey-Kun ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.