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

> А что есть m?

поле класса

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

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

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

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

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

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

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

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

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

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

> поле класса

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

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

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

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

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

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

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

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

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

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

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

using namespace qfrost, далее Rectangle.

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

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

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

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

учту

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

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

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

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

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

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

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

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

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

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

«Венгерская Нотация была изобретена программистом 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 имеет размерность в двойное слово, что, в общем, не говорит вам вообще ничего полезного. Таким образом, неудивительно, что люди восстали против Системной Венгерской. „

http://local.joelonsoftware.com/wiki/%D0%9A%D0%B0%D0%BA_%D0%B7%D0%B0%D1%81%D1...

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

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

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

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

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

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

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

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

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

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

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

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

Идиоматическая*

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

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

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

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

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

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

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

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

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

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

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();
}

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

кстати нафига тут вообще '&' ? o_O

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

2.

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

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

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

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

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

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

sizeof(T*) <= sizeof(T)

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

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

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

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

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

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

точняк :)

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

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

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

или как?

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

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

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

_В принципе_, да. )))

Но могут быть и.

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

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

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

ты тормоз или что? я писал про скорость

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

ты невменяем

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

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