Вопросы на внимательность, вполне обычные.

Но что в них раздражает, так это несоблюдение нотации.

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

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

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

Нормальными для кого? Для тебя? Им что нужно было спросить тебя какой coding style лично ты предпочитешь? Если неиспользование одного специфичного(из нескольких десятков) стайла напрягает, то это очень тревожный знак. На такие вещи стоит обращать внимания лишь когда встречается Drinks, CMartini, ground_hog одновременно.

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

А>Нормальными для кого?
Вроде как для M$ и её продуктов (ну там Win API, ATL, MFC и т. д...)...

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

А>>Нормальными для кого?
E>Вроде как для M$ и её продуктов (ну там Win API, ATL, MFC и т. д...)...

"Нормальность" очень сомнительный и трудноопределяемый критерий. Я бы говорил, скорее, о стандартности, и рассматривал бы соответствующую или самую распространенную библиотеку

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

DS>"Нормальность" очень сомнительный и трудноопределяемый критерий. Я бы говорил, скорее, о стандартности, и рассматривал бы соответствующую или самую распространенную библиотеку

По-твоему это нормально – когда имена классов ничем не отличаются от имён объектов?

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

А>Нормальными для кого? Для тебя? Им что нужно было спросить тебя какой coding style лично ты предпочитешь?

Нет, разумеется, на собеседованиях вообще желательно называть классы martini, drink, а объекты СDrinks, CCocktail. Все переменные-члены классов пообзывать чем-нить вроде i, j, k, x, y. А переменные в функциях наоборот m_iter1, m_alcohol. Ещё и имена функциям придумать позабористее, чтоб на апишные были похожи.

А на вопрос соискателя чё за нах сказать: “нам что, нужно было спросить тебя какой кодинг-стайл ты предпочитаешь? Дык если тебя взять на работу – ты может ещё и документацию попросишь? Тревожный знак, братан, какой же ты после этого программист?”

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

S>А на вопрос соискателя чё за нах сказать: “нам что, нужно было спросить тебя какой кодинг-стайл ты предпочитаешь? Дык если тебя взять на работу – ты может ещё и документацию попросишь? Тревожный знак, братан, какой же ты после этого программист?”
Ты кодинг-стайл говном-то не подменяй. Если кодинг-стайл другой — это одно, а если вместо него то, что ты описал, то другое.

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

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

DS>>"Нормальность" очень сомнительный и трудноопределяемый критерий. Я бы говорил, скорее, о стандартности, и рассматривал бы соответствующую или самую распространенную библиотеку

S>По-твоему это нормально – когда имена классов ничем не отличаются от имён объектов?

Не знаю, что думает об этом http://rsdn.ru/Users/9585.aspx, но, на мой фзгляд, это вполне нормально. А у тебя есть какие-либо статистические данные подтверждающие, что в этом случае могут быть проблемы?

Кстати, при использовании camel casing, имена объектов скорее всего, будут выглядеть так "имяОбъекта", а емена классов так "ИмяКласса", т.е. разница будет и без всяких там префиксов.

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

S>По-твоему это нормально – когда имена классов ничем не отличаются от имён объектов?

Определение "нормальности" в студию. Если говорить о вкусах, то мне не составляет труда читать/писать в стандартном стиле.
Вообще же, приходилось видить разное и забавное: например, стандартный стиль + все имена полей классов с "m_", что по первости без улыбки читать трудно

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

E>Вроде как для M$ и её продуктов (ну там Win API, ATL, MFC и т. д...)...
У кого-то из классиков было довольно убедительное объяснение по этому поводу.
С одной стороны когда создавался MFC C++ был еще на зачаточном уровне и пространства имён были только в проекте, с другой была масса C кода который пользователям хотелось переиспользовать, поэтому и ввели костыль в виде "C"-префикса (т.е. возможно у кого-нибудь в коде и встречается Button, но CButton — мало ввероятно). Поэтому префикс "C" следует считать зарезервированным за МС и никогда не использовать в своих классах (если Вы написали убер класс CImageButton а через пару лет МС добавила в MFC класс с таким же именем, угадайте кому придётся переписывать код .

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

А>если Вы написали убер класс CImageButton а через пару лет МС добавила в MFC класс с таким же именем, угадайте кому придётся переписывать код .

Тому, кто пользуется MFC?

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

E>Тому, кто пользуется MFC?

Тому, кто не пользуется namespace-ами.

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

S>>По-твоему это нормально – когда имена классов ничем не отличаются от имён объектов?

C>Не знаю, что думает об этом http://rsdn.ru/Users/9585.aspx, но, на мой фзгляд, это вполне нормально. А у тебя есть какие-либо статистические данные подтверждающие, что в этом случае могут быть проблемы?

Ну проблемы — это сильно сказано.

Но если где-то есть класс drink, а потом вдруг появляется объект drinks, то мой взгляд начинает об него спотыкаться. Не сильно, но достаточно чтобы повлиять на концентрацию.

Хз, может это я просто такой чайник, а настоящим профи такие мелочи нипочём.

Но в любом случае зачем усложнять жизнь там где в этом нет необходимости?

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

А>Поэтому префикс "C" следует считать зарезервированным за МС и никогда не использовать в своих классах (если Вы написали убер класс CImageButton а через пару лет МС добавила в MFC класс с таким же именем, угадайте кому придётся переписывать код .

Вообще классный аргумент! Переименовать класс это ведь такая большая проблема!!!
А для писателей библиотек просто огромная проблема добавить приставку CMYLIB к классу
Давайте так, угадайте за 5 лет работы сколько раз мне требовалось переименовать класс т.к. он конфликтовал с другим?

Sealcon190, я поддержу тебя в этом вопросе, самого жутко расстраивает.
Приставки — это прекрасно! Почему их люди не используют повсеместно? Ну они это как то объясняют (ИМХО, им просто лень лишний раз жать баттоны)

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

Z>А для писателей библиотек просто огромная проблема добавить приставку CMYLIB к классу
Такому бы писателю да кое-чего кое-куда огого как.

Z>Приставки — это прекрасно!
<нас всех тошнит>

Z>Почему их люди не используют повсеместно?
namespace это не модно?

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

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

Z>>А для писателей библиотек просто огромная проблема добавить приставку CMYLIB к классу
DS>Такому бы писателю да кое-чего кое-куда огого как.
Ну приставки — это конечно перебор. И если уж и писать приставку, то без "С", подобно wxWidgets с его wxString, wxButton,...
Ну и создателям Qt за их приставочку Q тоже получается надо кое-чего кое-куда

Z>>Приставки — это прекрасно!
DS><нас всех тошнит>
Не надо ля ля за всех.
Что плохого в приставках?
IMartini — сразу видно, что интерфейс
CMartini — а вот и класс нарисовался
а что такое Martini/martini? переменная, класс, пространство имён, функция или еще чего?

Z>>Почему их люди не используют повсеместно?
DS>namespace это не модно?
Приставки нужны не для уникальной идентификации типов.
Некоторые, например, рекомендуют указатели называть с приставкой "p" (pFirst, pNext,...) и члены классов с приставкой "m" (mInstance, mMember,...) и всё в этом духе. Эти все приставки не для уникальности же рекомендуются, а чтобы сразу видеть, что здесь указатель, а это вот приватный член класса используется. Так что namespace несколько из иной оперы и назначение у них другое.

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

А>Ну и создателям Qt за их приставочку Q тоже получается надо кое-чего кое-куда

Z>>>Приставки — это прекрасно!
DS>><нас всех тошнит>
А>Не надо ля ля за всех.
boostShPtr2stdSet, кому хорошо?
А>Что плохого в приставках?
Приставки не нужны. Как и суффиксы.
А>IMartini — сразу видно, что интерфейс
Что это?
А>CMartini — а вот и класс нарисовался
Виртуальные функции с V, статические — c S, шаблоны — с Ш^WT, в названии так же отражать ограничения на принимаемые аргументы.
А>а что такое Martini/martini? переменная, класс, пространство имён, функция или еще чего?
А что такое mi?
Z>>>Почему их люди не используют повсеместно?
Потому что это даже не костыли.
DS>>namespace это не модно?
А>Приставки нужны не для уникальной идентификации типов.
Z>>А для писателей библиотек просто огромная проблема добавить приставку CMYLIB к классу
z>Так что namespace несколько из иной оперы и назначение у них другое.
Это что, случайная газификация естественного микроводоема?
А>Некоторые, например, рекомендуют указатели называть с приставкой "p" (pFirst, pNext,...) и члены классов с приставкой "m" (mInstance, mMember,...) и всё в этом духе.
"Некоторые" британские ученые, ога. Источники будем приводить?
A>Эти все приставки не для уникальности же рекомендуются, а чтобы сразу видеть, что здесь указатель, а это вот приватный член класса используется.
Если не видно, что это — указатель, а вот это — приватное поле, то, может, что-то не правильно в консерватории?

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

DS>boostShPtr2stdSet, кому хорошо?
Ну это конечно перебор. Я привел пример адекватных приставок wxWidgets'a. 1-2 символа не напряжно писать, но информативно. К тому же конфликты имён будут и с использованием пространств имён, ибо обычно в начале написали:
using namespace xxx;
using namespace yyy;
а дальше без явного указания пространств пошли использовать всё подряд. Но тут конечно компилятор спросит в конфликтных местах чего именно хотите и явно указать пространство потребует. Но конечно вопрос насколько это возможно при использовании таких крупных библиотек, ибо маловероятно использование строк из STL, если работаем с виджетами.

А>>IMartini — сразу видно, что интерфейс
DS>Что это?
Не знаете что такое интерфейс? Ну можно обозвать это абстрактным базовым классом с большой натяжкой и обозвать MartiniBase, только тут уже некрасивый суффикс вылазиет...
А>>CMartini — а вот и класс нарисовался
DS>Виртуальные функции с V, статические — c S, шаблоны — с Ш^WT, в названии так же отражать ограничения на принимаемые аргументы.
Ага. Забыли что-то еще про наследование. Обязательно в именах классов отражать от каких классов они унаследованы, как и зачем и обязательно до седьмого колена, чтобы далеко в исходники не лазить...
А>>а что такое Martini/martini? переменная, класс, пространство имён, функция или еще чего?
DS>А что такое mi?
это нота такая. ага.
z>>Так что namespace несколько из иной оперы и назначение у них другое.
DS>Это что, случайная газификация естественного микроводоема?
namespace нужны для избежания конфликта имён и для сбора отдельных запчастей во что-то напоминающее монолитную библиотеку. Приставки и суффиксы нужны чтобы показать who is who.
А>>Некоторые, например, рекомендуют указатели называть с приставкой "p" (pFirst, pNext,...) и члены классов с приставкой "m" (mInstance, mMember,...) и всё в этом духе.
DS>"Некоторые" британские ученые, ога. Источники будем приводить?
Ну скажем урезанная версия венгерской нотации без этих маниакальных nSize, bFlag из-за которых при смене типа переменной, придется менять её имя. Указатель на что-то другое если изменится, то корректировать их использование так и так придется и можно уж и переименовать попутно. Члены классов так же врядли чем-то другим станут. Всякие pcsz и т.п. огород городить перед именем переменной — это конечно перебор, но я этого и не предлагаю. Всё хорошо в меру
DS>Если не видно, что это — указатель, а вот это — приватное поле, то, может, что-то не правильно в консерватории?
Сейчас видно в вашем коде, а завтра в чужом непонятно что за переменная такая. К чему совершать лишние телодвижения типа "Go to Definition", с перескакиванием в другой файл, чтобы узнать что сие перед нами приватное поле, а не глобальная переменная? Современные IDE и примочки к ним конечно могут предоставить и более удобное определение, но наглядность — она и в африке наглядность.
Ну ладно еще с учетом развития в плюсах умных указателей и IDE можно забить на приставки к указателям и другим переменным вместе с полями класса, но как показать, что это именно интерфейс, а не класс? Коммент писать? Макросом добавлять псевдо-ключевое слово interface? Как по мне, так я лучше приставку I напишу. А потом у меня появляется класс Ivan и выглядит он теперь как интерфейс. Если на абстрактных классах реализовывать, а не интерфейсах, то всплывут суффиксы типа "Base" и "Impl".
Опять же если брать STL, то там даже классы с маленькой буквы нормально живут, но они там все на шаблонах, да и кто напишет что-то вроде: "string String" или "vector<int> Vector"?
А вот Query query вполне могут написать. Разница всего в один символ грозит возможностью опечаток с неожиданными текстами ошибок. Вместо: "неизвестный идентификатор" получим ошибку про отсутствие конструктора или еще чего в этом роде, а если перегружен оператор (), то Query("ы") вместо query("ы") (и наоборот), может к интересному результату привести.

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


А>Ну это конечно перебор. Я привел пример адекватных приставок wxWidgets'a.
приставки в популярных библиотеках вызваны суровой необходимостью баиндинга имен на C, что позволяет легко использовать эти библиотеки в других языках. По причине отсутствия namespaces в C, разработчики вынуждены вводить вот такие костыли, да. К C++ это имеет опосредованое отношение.
А>using namespace xxx;
А>using namespace yyy;
А>а дальше без явного указания пространств пошли использовать всё подряд.
using std::ostream;
typedef std::ostream default_stream;
подумайте над этим, перед тем как делать using на весь namespace.
А>Но тут конечно компилятор спросит в конфликтных местах чего именно хотите и явно указать пространство потребует. Но конечно вопрос насколько это возможно при использовании таких крупных библиотек, ибо маловероятно использование строк из STL, если работаем с виджетами.
Не понял смысла предложения.
А>Не знаете что такое интерфейс?
Если мы все еще говорим о C++, то единственное, что мне приходит в голову — это интерфейс класса. В это понятие включаются все публичные методы и поля класса, а так же часть свободных функций, работающих с экземплярами класса. В более расширенном понимании сюда относят и protected методы/поля.
А>Ну можно обозвать это абстрактным базовым классом с большой натяжкой и обозвать MartiniBase
Вы не поверите, но "абстрактный базовый класс" называется в C++ абстрактным базовым классом. Понятия "абстрактный базовый класс с большой натяжкой" это из какого-то другого языка. В котором, впрочем есть ключевое слово Interface.
А>Ага. Забыли что-то еще про наследование. Обязательно в именах классов отражать от каких классов они унаследованы, как и зачем и обязательно до седьмого колена, чтобы далеко в исходники не лазить...
Смотрю, вы меня хорошо поняли. Да, и в реальном проекте наследование до 7 колена как бэ намекает.
А>Сейчас видно в вашем коде, а завтра в чужом непонятно что за переменная такая.
Пойти и задать два простых вопроса. Что за переменная, и почему я не понимаю этого сразу.
А>К чему совершать лишние телодвижения типа "Go to Definition", с перескакиванием в другой файл, чтобы узнать что сие перед нами приватное поле, а не глобальная переменная?
А>Современные IDE и примочки к ним конечно могут предоставить и более удобное определение, но наглядность — она и в африке наглядность.
Узнаю что глобальная переменная -- опозорю на всю контору. Да, и при чем сдесь IDE и ваше незнание сочетания клавиши Ctrl-Tab? Давайте все же о предмете. Про наглядность -- полностью согласен.
А>Ну ладно еще с учетом развития в плюсах умных указателей и IDE
Нету в C++ IDE. Нету.
A>можно забить на приставки к указателям и другим переменным вместе с полями класса, но как показать, что это именно интерфейс, а не класс?
Да я вообще не понимаю, что за интерфейс такой.
А>Опять же если брать STL, то там даже классы с маленькой буквы нормально живут, но они там все на шаблонах, да и кто напишет что-то вроде: "string String" или "vector<int> Vector"?
Шаблоны, похоже, отменяют все правила, да? Хорошо, что boost тоже на стероид^Wшаблонах. А то вот бы я сейчас мучился.
А>А вот Query query вполне могут написать. Разница всего в один символ грозит возможностью опечаток с неожиданными текстами ошибок. Вместо: "неизвестный идентификатор" получим ошибку про отсутствие конструктора или еще чего в этом роде, а если перегружен оператор (), то Query("ы") вместо query("ы") (и наоборот), может к интересному результату привести.
Тяжела и неказиста жизнь простого программиста.

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

DS>Да я вообще не понимаю, что за интерфейс такой.
Ну COM с его IUnknown и т.п. суповым набором. интерфейс != абстрактный класс, а потому надо как-то отразить, что за неимением в плюсах "interface" мы это объявили классом, но всёже это является интерфейсом. Ну и использовать ООП подход на интерфеях можно не только для COM... Ну да ладно. Не будем в дебри не по теме заходить, а то сейчас начнется, что это не тру сишный подход и за этим на яву или шарп переходить надо
А>>Опять же если брать STL, то там даже классы с маленькой буквы нормально живут, но они там все на шаблонах, да и кто напишет что-то вроде: "string String" или "vector<int> Vector"?
DS>Шаблоны, похоже, отменяют все правила, да? Хорошо, что boost тоже на стероид^Wшаблонах. А то вот бы я сейчас мучился.
Не отменяют. Просто специфика классов из STL и работы с шаблонами в плюсах минимизируют возможность глупых ошибок от невнимательности. Если бы в STL были CString и CVector, мне бы это не мешало ни капельки. Ну а за неимением выбора, пришлось привыкать, что классы без приставок, да еще и с маленькой буквы.

Я просто не понимаю в чем недостаток той же приставки "С" у классов? Лишний символ писать надо и это напрягает? Или то, что это майкрософт любит использовать и когда-то возможно ваш класс может пересечься с классом из MFC? В общем мне интересно: что в этих приставках не так? Может я о каких-то их недостатках не догадываюсь? Я сейчас без иронии говорю. Просто, пока не поздно, надо отвыкать так классы называть и писать "нормально", если конечно это не Ваше субъективное ИМХО, что приставки — зло. Ну и опять же как нормально? Класс с большой буквы называть без приставок всяких или как в STL — с маленькой?
Если брать делфю, то там по стандартному набору классов видно, что рекомендуется писать приставку "T".
В шарпе без приставок всяких, хотя тот же майкрософт, который в плюсах пишет "С" (почему опять же? одумались со времен MFC и поняли, что приставка не нужна?).
Получается тогда, что надо и в плюсах ориентироваться на стандартную библиотеку STL в оформлении?