Венгерская нотация, оно вообще надо?

@bumbaram · Регистрация: 13.02.2012

Author24 — интернет-сервис помощи студентам

Вопрос в заголовке. Больше всего смущает префикс m_ для приватных членов класса, ни информативности на красоты, а печатать дольше. Общее мнение рудимент или хороший стиль?

silent_1991 · 01.02.2013, 23:11

Сообщение от MrGluck

тем, что не является буквой и не коверкает запись, ассоциацию. Например было isPrint (переменная, отвечающая надо ли выводить на печать объект) стало m_isPrint - опечаткой. Была руда ore, стала m_ore - "больше".

Да ладно вам, с моей точки зрения аргументы притянуты за уши. Если бы не было нижнего подчёркивания - был бы полностью с вами согласен. Однако оно есть, и это кардинально меняет картину.
Однако никому своё мнение на навязываю, естественно. Кто как хочет - тот так и пишет. Главное - следовать корпоративным стандартам кодирования - и всё будет замечательно!

@Dmitriy_M · 02.02.2013, 14:37

Сообщение от hinst

так всё и есть, только я про смену типа, а не про смену имени переменной.

Пример давай. Тип переменной от каста не меняется.

Сообщение от hinst

this->

усложняет чтение.

Сообщение от MrGluck

тем, что не является буквой и не коверкает запись, ассоциацию. Например было isPrint (переменная, отвечающая надо ли выводить на печать объект) стало m_isPrint - опечаткой. Была руда ore, стала m_ore - "больше".

Не аргумент. Если не используются символы _, для разделения слов(signal_number), то m_ ассоциируется как method.
В случает с m_ore и more, это в какой конвенции можно спутать?

Сообщение от silent_1991

Главное - следовать корпоративным стандартам кодирования - и всё будет замечательно!

Нужно придерживаться одного стиля внутри проекта. Особенно актуально в OpenSource проектах.

silent_1991 · 02.02.2013, 15:01

Сообщение от Dmitriy_M

m_ ассоциируется как method

member всё-таки...

Сообщение от Dmitriy_M

Нужно придерживаться одного стиля внутри проекта.

А это как-то опровергает моё высказывание?

XRuZzz · 07.02.2013, 10:12

сокращенные суффиксы и префиксы вытесняют (как бы занимают ваше внимание) осмысленные названия сущностей.
Чем короче и понятнее название переменной или атрибута класса тем лучше.
Пример

C++

1	Dates dateOfBirth;

из названия ясно, что речь идёт о дате, уже можно примерно догадываться о типе.
Или другой пример например атрибут класса Dates

C++

class Dates
{
    public:
       ...
       void setDay(int);
       int getDay();
    private:
       int day;

попробуем то же самое сделать с помощью венгерской нотации

C++

class СDates
{
    public:
       ...
       void setM_iDay(int);                    // ???
       int getM_iDay();                         // ???
    private:
       int m_iDay;

Такой результат может получиться при автоматической генерации сеттеров геттеров с помощью IDE.(ведь код должен быть устойчив к обработке разными IDE)

Другое дело указатели

C++

1	Dates *pDateOfBirth;

IDE возможно сама узнает префикс p и корректно с генерирует сеттеры и геттеры. Но я их иногда привожу к виду:
setDateOfBirthPointer

Добавлено через 11 минут
в реальности (в Eclipse) получилось так

C++

...
        int getIHouseNumber() const;
        void setIHouseNumber(int iHouseNumber);
    private:
        int m_iHouseNumber;
...

но мне даже буква I в сеттерах геттерах не нужна.

@OhMyGodSoLong · 07.02.2013, 10:22

Джоэль как-то уже плакался на эту тему (rooskie). Что люди нихрена не понимают, что такое настоящая венгерская нотация.

silent_1991 5055 / 3115 / 271 Регистрация: 11.11.2009 Сообщений: 7,044
	01.02.2013, 23:11	21
	Сообщение от MrGluck тем, что не является буквой и не коверкает запись, ассоциацию. Например было isPrint (переменная, отвечающая надо ли выводить на печать объект) стало m_isPrint - опечаткой. Была руда ore, стала m_ore - "больше". Да ладно вам, с моей точки зрения аргументы притянуты за уши. Если бы не было нижнего подчёркивания - был бы полностью с вами согласен. Однако оно есть, и это кардинально меняет картину. Однако никому своё мнение на навязываю, естественно. Кто как хочет - тот так и пишет. Главное - следовать корпоративным стандартам кодирования - и всё будет замечательно! 0

@OhMyGodSoLong ~ Эврика! ~ 1256 / 1005 / 74 Регистрация: 24.07.2012 Сообщений: 2,002
	07.02.2013, 10:22	25
	Джоэль как-то уже плакался на эту тему (rooskie). Что люди нихрена не понимают, что такое настоящая венгерская нотация. 2

@bumbaram 47 / 47 / 9 Регистрация: 13.02.2012 Сообщений: 176
		1
	Венгерская нотация, оно вообще надо? 22.01.2013, 16:54. Показов 5608. Ответов 24 Метки нет (Все метки) Вопрос в заголовке. Больше всего смущает префикс m_ для приватных членов класса, ни информативности на красоты, а печатать дольше. Общее мнение рудимент или хороший стиль? 0

@Dmitriy_M 1443 / 1326 / 131 Регистрация: 20.03.2009 Сообщений: 4,689 Записей в блоге: 11
	02.02.2013, 14:37	22
	Сообщение от hinst так всё и есть, только я про смену типа, а не про смену имени переменной. Пример давай. Тип переменной от каста не меняется. Сообщение от hinst this-> усложняет чтение. Сообщение от MrGluck тем, что не является буквой и не коверкает запись, ассоциацию. Например было isPrint (переменная, отвечающая надо ли выводить на печать объект) стало m_isPrint - опечаткой. Была руда ore, стала m_ore - "больше". Не аргумент. Если не используются символы _, для разделения слов(signal_number), то m_ ассоциируется как method. В случает с m_ore и more, это в какой конвенции можно спутать? Сообщение от silent_1991 Главное - следовать корпоративным стандартам кодирования - и всё будет замечательно! Нужно придерживаться одного стиля внутри проекта. Особенно актуально в OpenSource проектах. 0

silent_1991 5055 / 3115 / 271 Регистрация: 11.11.2009 Сообщений: 7,044
	02.02.2013, 15:01	23
	Сообщение от Dmitriy_M m_ ассоциируется как method member всё-таки... Сообщение от Dmitriy_M Нужно придерживаться одного стиля внутри проекта. А это как-то опровергает моё высказывание? 0