Здравствуйте, Erop, Вы писали:

E>Здравствуйте, crable, Вы писали:

C>>...то что могло помешать этому человеку начхать на все эти суффиксы/префиксы (если они используются) и написать так
C>>

C>>Drink( CMaritini() );
C>>

E>При просмотре кода, в этом случае видно, что тут скорее всего ошибка...

Какя же тут ошибка, по виду это вызов функции Drink с временным объектом класса CMartini в качестве аргумента. То, что Drink не функция, а тип, а CMartini не класс а функция отсюда не видно. Всё тоже самое, что и в случае с

drink( martini() );

Здравствуйте, zitz, Вы писали:

Z>Да я пишу перед указателем p, перед членом класса m_, перед статическими переменными st_, перед названием переменной её тип b, dw, i, — потому что мне это удобно.
А где конкретный тип переменной играет значение? Обычно компилятор впоне справляется с провверкой типизации, а для прикладного приложения в подавляющем большинстве случаев не важно является ли переменная типа dword или int.

Я бы предпочёл видеть в качестве названия переменной isAlcohilicDrink нежели bFlag и numberOfIceCubesInDrink чем iIce. Одно кончено не запрещает другого, просто на мой взгляд нормальное название переменной играет гораздо большую роль чем использование префиксов, а мой оптыт подсказывает что префиксы чаcто используются именно с переменными типа bNum, где без них вообще крышу сносит.

Здравствуйте, zitz, Вы писали:

Z>Здравствуйте, Alexander G, Вы писали:

S>>>С нормальными названиями классов, CDrinks, CMartini, CAnimal, CGroundHog, лично мне было бы легче сосредоточиться, а так как есть – здорово запутывает и отвлекает от основной задачи.

AG>>Иногда в одном и том же проекте используются, например, Boost (с STL-way стилем), WTL (с MFC-way стилем), ну и десяток всячеких libastralов. Как же можно работать в таких проектах!?

Z>Если не использовать using, то просто дописываете std:: или boost:: — это сразу видно, что код от туда

Со спиритом без using слишком мрачно. А, кроме того, префикс boost не изменит соглашений о вызовах в boost. И свой код, реализующий какой-либо бустовский интерфейс будет тоже содержать всякие void intrusive_ptr_add_ref(T*) и T& it::dereference(). Смешения стилей не избежать.

Z>Над другими библиотеками я делаю обёртки, чтобы минимизировать количество "плохого" кода.

Не вегда целесообразно это.

Здравствуйте, Erop, Вы писали:

foo()
{
    bar1( bar2() ); // bar -- это класс или функция? :shuffle: 
}

Так ли это важно? Сегодня класс, завтра функция.

—Это борщ или помои? — спрашивает возмущенный посетитель столовой.
—А вы что, не можете сами определить?
—Нет!
—Так какая вам разница? — равнодушно отвечает раздатчица.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Erop, Вы писали:

А>

foo()
А>{
А>    bar1( bar2() ); // bar -- это класс или функция? :shuffle: 
А>}

А>Так ли это важно? Сегодня класс, завтра функция.

Послезавтра макрос...

Здравствуйте, crable, Вы писали:

C>Какя же тут ошибка, по виду это вызов функции Drink с временным объектом класса CMartini в качестве аргумента. То, что Drink не функция, а тип, а CMartini не класс а функция отсюда не видно. Всё тоже самое, что и в случае с
C>

C>drink( martini() );
C>

Ну так, IMHO, это и показывает полезность префиксов такого рода...

Здравствуйте, Alexander G, Вы писали:

AG>Смешения стилей не избежать.
Z>>Над другими библиотеками я делаю обёртки, чтобы минимизировать количество "плохого" кода.
AG>Не вегда целесообразно это.

Ну да. Тут главное без фанатизма
Если проект предпологается большой, требующей постоянной поддержки — то лучше один раз помучатся Потраченное время окупится.
Я так и написал:
Z>>В общем всё от ситуации зависит

Здравствуйте, <Аноним>, Вы писали:

А>А где конкретный тип переменной играет значение? Обычно компилятор впоне справляется с провверкой типизации, а для прикладного приложения в подавляющем большинстве случаев не важно является ли переменная типа dword или int.

Мы же код оформляем не для компилятора
Всё это становится важным в момент дописывания кода.

А>Я бы предпочёл видеть в качестве названия переменной isAlcohilicDrink нежели bFlag и numberOfIceCubesInDrink чем iIce. Одно кончено не запрещает другого

Естественно нормальное название гораздо лучше, чем приставка+не_нормальное. Эти вещи сравнивать нельзя, одно дополняет другое.

Здравствуйте, Аноним, Вы писали:

А>>Так ли это важно? Сегодня класс, завтра функция.

А>Послезавтра макрос...

А хоть бы и макрос.

GetSystemInfo, GetVersionEx, GetProcAddress, CreateIconIndirect, CreateFontIndirect — здесь есть и макросы и функции.

Здравствуйте, zitz, Вы писали:

Z>Мы же код оформляем не для компилятора
Z>Естественно нормальное название гораздо лучше, чем приставка+не_нормальное. Эти вещи сравнивать нельзя, одно дополняет другое.
Так какой от этого бенефит для обычного смертного? Какая разница numberOfIceCubesInDrink типа int или dword? И не предлагайте туда присвоить -1, отрицательного количества льда не бывает. Где-то это возможно и надо, если например надо биты считать, но в прикладном программировании имхо это скорее исключение чем правило.

При чём, ни разу не видел чтобы делали префиксы в стиле myclassItem, а вот и целыми и указателями сплошь и рядом. Это на тот случай если MS решит включить этот кусок кода в винду и он там органично смотрелся? Ещё бывают хитрые typedef-ы типа std::string::size_type, не называть же переменную sstIndex.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, crable, Вы писали:

C>>Какя же тут ошибка, по виду это вызов функции Drink с временным объектом класса CMartini в качестве аргумента. То, что Drink не функция, а тип, а CMartini не класс а функция отсюда не видно. Всё тоже самое, что и в случае с
C>>

C>>drink( martini() );
C>>

E>Ну так, IMHO, это и показывает полезность префиксов такого рода...

Так если никакой разницы, в чём полезность-то?

Здравствуйте, crable, Вы писали:

E>>Ну так, IMHO, это и показывает полезность префиксов такого рода...
C>Так если никакой разницы, в чём полезность-то?

Ну я не знаю что и как ты понимаешь, а мне вот очевидно

    Используешь нотацию => подозрительные места видно
    Не используешь => подозрительные места не видно

IMHO, ты сам это показал довольно убедительно...

Здравствуйте, Sealcon190, Вы писали:

S>С нормальными названиями классов, CDrinks, CMartini, CAnimal, CGroundHog, лично мне было бы легче сосредоточиться, а так как есть – здорово запутывает и отвлекает от основной задачи.

Я когда развлекаюсь программированием чисто для себя вечерами и по выходным, люблю такую нотацию, что типы обозначаю суффиксом _t а данные-члены префиксом m_. И ещё я ненавижу большие буквы Поэтому alcohol_t martini; martini.m_degree = 15;

Но когда выходные кончаются и я выхожу на работу я всё делаю в соответствии с принятым там стилем кодинга. И там для меня не составит труда написать: CAlcohol Martini; Martini.degree_ = 15;

Или любым другим стилем, ага. Поскольку в жизни я работал уже в трёх принципиально не схожих друг с другом конторах с иногда диаметрально противоположными требованиями к стилю.

Это всё к чему... Нет "нормальных названий классов". Не бывает. Название это лишь название и если за ним вы не видите мысль, то это, как мне кажется, вполне достаточное основание рассмотреть вместо вас тех кандидатов которые не будут воротить красивый эльфийский нос от кода написанного скажем 15 лет назад в котором всё это будет так, как и в страшном сне не всегда бывает.

Здравствуйте, <Аноним>, Вы писали:

А>Так какой от этого бенефит для обычного смертного?

Для вас похоже разницы нет. Может вы переросли это, я нет.
Для меня огромное значение имеет информация которую я могу окинуть взглядом и чем больше она тем лучше. Мне нужно знать когда я дописываю код, член это класса передо мною или нет, переполнится тип или нет, может туда отрицательное значение попасть или нет, банально строка передо мной, массив, число или указатель и так далее, т.е. еще раз:
Всё это становится важным в момент дописывания кода.
Возможно вы делаете сразу идеальную расширяемую архитиктору, код пишите без ошибок и высокой степени абстракции, возможно вы достигли дао программирования и вам всё это не требуется — это прекрасно.
А мне это очень помогает каждый день, пока особых минусов не заметил.
m_p_arrCurrTask — указатель на массив текущих задач, это член класса, значит будет использован за пределами функции которую я редактирую, туда ноль может попасть, нужно проверку делать перед использованием и т.д. Т.е. для меня это большой пласт информации которую я получил только взглянув на переменную.
К классу дописываю C — т.к. для меня важно отличать класс от функции моментально, виртуальным функциям которые вызываются "самостоятельно" при каком то событии, делаю приставку On и так далее. В общем применение приставок довольно обширно.

А>При чём, ни разу не видел чтобы делали префиксы в стиле myclassItem, а вот и целыми и указателями сплошь и рядом.

Я пишу (только не такие длинные и в тех случаях что мне нужно)

А>Ещё бывают хитрые typedef-ы типа std::string::size_type, не называть же переменную sstIndex.

Как её назвать это ваше дело, но если эта переменная ипользуется на учатке протяжонностью более 5 строк, я бы дал ей приставку и название нормальное

Да и вообще каким смыслом нагружать приставку это ваше дело, главное чтобы везде одинаково было. Можно использовать приставку чтобы указать тип (если это важно), можно использовать приставку чтобы указать что это исходящий например параметр outVar (если это важно), можно чтобы указать что это массив arrNumbers (если это важно), можно даже так blobValue. Всё зависит от необходимости, на что следуюет обратить внимание, как с этим проще работать. Можно принципиально не использовать приставки... только зачем?

Здравствуйте, <Аноним>, Вы писали:

А>Так какой от этого бенефит для обычного смертного? Какая разница numberOfIceCubesInDrink типа int или dword? И не предлагайте туда присвоить -1, отрицательного количества льда не бывает. Где-то это возможно и надо, если например надо биты считать, но в прикладном программировании имхо это скорее исключение чем правило.

dw это взят мною "свежак" из последнего кода, там очень важно это dw или dwl или w
Если важен знак то ui или i.
Я же не говорю что нужно повсеместно тип переменной дописывать. Случаи разные бывают
Обычно хватает приставки которая говорит что внутри — число, строка, булево значение.
В приведенном вами примере numberOfIceCubesInDrink = nIceCubesInDrink, для меня это равнозначно. n — это number of, p — это pointer to, m_ — member of

Здравствуйте, zitz, Вы писали:

Да я, собсвтенно сам использую префиксы m_ и g_ даже если подсветка настроена — дифы потом удобнее просматривать.

Z>m_p_arrCurrTask — указатель на массив текущих задач
Меня конкретный тип волнует не так часто. Я бы назвал m_currentTaskList — сегодня это указатель на массив, завтра умный указатель на вектор, после завтра может быть вообще полноценный объект. Если в коде перепутать '.' с '->', то код просто не будет компилироваться.

Z>туда ноль может попасть, нужно проверку делать перед использованием и т.д.
Согласен, в этом случае приставка p действительно имеет смысл.

Z>Да и вообще каким смыслом нагружать приставку это ваше дело, главное чтобы везде одинаково было. Можно использовать приставку чтобы указать тип (если это важно), можно использовать приставку чтобы указать что это исходящий например параметр outVar (если это важно), можно чтобы указать что это массив arrNumbers (если это важно), можно даже так blobValue. Всё зависит от необходимости, на что следуюет обратить внимание, как с этим проще работать. Можно принципиально не использовать приставки... только зачем?
На мой взгляд приставки в большинстве случаев несут на порядок меньше информации чем остальное имя, с другой стороны именно остальным именем в С/C++ гораздо чаще пренебрегают (видимо UNIX культура даёт о себе знать). На заре карьеры мне повезло работать с замечательным промышленным кодом возраста > 15 лет, содержаищим имена переменных вида bufferSizeInBytes и taskDelayInMilliseconds после которых от имён типа dwTimeout меня передёргивает — каждый раз нужно лезть или в исходный код или в случае его отсутствия в документацию чтобы понять в чём этот таймаут определяется в этом месте. И я не думаю что за всё время существования кому-ниблудь на планете захотелось присвоить в таймаут значение > 2x10^9. На самом деле при "нормальном" имени в том или ином виде информация о типе часто присутствует, например isEmpty или hasTasks, но в отличие от приставок она более человечная что ли. С одной стороны это увеличивает абстракцию, с другой уменьшает знание о конкретном типе.

Здравствуйте, zitz, Вы писали:

Z>Я же не говорю что нужно повсеместно тип переменной дописывать. Случаи разные бывают
Именно

Z> nIceCubesInDrink
Nice, very nice cubes

Здравствуйте, zitz, Вы писали:

Z>Здравствуйте, <Аноним>, Вы писали:

А>>Так какой от этого бенефит для обычного смертного? Какая разница numberOfIceCubesInDrink типа int или dword? И не предлагайте туда присвоить -1, отрицательного количества льда не бывает. Где-то это возможно и надо, если например надо биты считать, но в прикладном программировании имхо это скорее исключение чем правило.

Z>dw это взят мною "свежак" из последнего кода, там очень важно это dw или dwl или w
Z>Если важен знак то ui или i.
Z>Я же не говорю что нужно повсеместно тип переменной дописывать. Случаи разные бывают
Z>Обычно хватает приставки которая говорит что внутри — число, строка, булево значение.
Z>В приведенном вами примере numberOfIceCubesInDrink = nIceCubesInDrink, для меня это равнозначно. n — это number of, p — это pointer to, m_ — member of

Зачем столько сложностей? современные IDE имеют семантическую подсветку синтаксиса, там глобальные — локальные — статические мемберы очень наглядно выделяются цветом. А тип объекта узнается во всплывающем попап окне, просто при наведении мышью на переменную.

Здравствуйте, catBasilio, Вы писали:

B>Зачем столько сложностей? современные IDE имеют семантическую подсветку синтаксиса, там глобальные — локальные — статические мемберы очень наглядно выделяются цветом. А тип объекта узнается во всплывающем попап окне, просто при наведении мышью на переменную.

А не все вот IDE пользуются. Я, например, код подчинённых обычно с бумажки читаю, или в блокноте...

Здравствуйте, Tilir, Вы писали:

T>Я когда развлекаюсь программированием чисто для себя вечерами и по выходным, люблю такую нотацию, что типы обозначаю суффиксом _t а данные-члены префиксом m_. И ещё я ненавижу большие буквы Поэтому alcohol_t martini; martini.m_degree = 15;

Меня вот слегка коробит от martini.m_degree = 15. Всё время кажется, что "m_*" — это что-то личное, которое нельзя вот так вот "=15" Другое дело martini.set_degree(15) или martini.degree = 15. То есть, хочется, чтобы запись выглядела ближе к естественному языку. Но аксессоры писать лень(тем более, если это просто get-set), поэтому чаще склоняюсь к martini.degree = 15. Хотя согласен, в этом случае, даже если это просто struct martini { unsigned degree; }, возможны проколы, чего стоит martini::martini(unsigned degreee) : degreee(degreee) {} Но это уже немного не про то...