Какой префикс вы используете для переменных-членов?

Question

Несомненно, для понимания кода важно назначить переменным-членам префикс, чтобы их можно было легко отличить от «обычных» переменных.

Но какой префикс вы используете?

Я работал над проектами, в которых мы использовали m_ в качестве префикса, в других проектах мы использовали только подчеркивание (что мне лично не нравится, потому что только подчеркивание недостаточно демонстративно).

В другом проекте мы использовали форму длинного префикса, которая также включала тип переменной. Например, mul_ - это префикс переменной m типа u nsigned l ong.

Теперь дайте мне знать, какой префикс вы используете (и, пожалуйста, укажите причину).

РЕДАКТИРОВАТЬ: Большинство из вас, кажется, кодируют без специальных префиксов для переменных-членов! Это зависит от языка? Исходя из моего опыта, C ++ код имеет тенденцию использовать подчеркивание или m_ в качестве префикса для переменных-членов. А как насчет других языков?

Answer 1

Без сомнения, для понимания кода важно назначить переменным-членам префикс, чтобы их можно было легко отличить от «обычных» переменных.

Я оспариваю это требование. Это не совсем необходимо, если у вас есть полуприличная подсветка синтаксиса. Хорошая среда разработки может позволить вам написать свой код на удобочитаемом английском языке, а также может показать вам тип и область действия символа другими способами. Eclipse хорошо выполняет свою работу, выделяя объявления и использует символ, когда точка вставки находится на одном из них.

Редактируйте, спасибо slim: Хороший инструмент подсветки синтаксиса, такой как Eclipse, также позволит вам использовать жирный или курсивный текст или вообще менять шрифты. Например, мне нравится курсив для статических вещей.

Другое редактирование: думай об этом так; тип и область действия переменной являются вторичной информацией. Это должно быть доступно и легко узнать, но не кричать на вас. Если вы используете префиксы, такие как m_ или такие, как LPCSTR, это становится помехой, когда вы просто хотите прочитать основную информацию - намерение кода.

Третье редактирование: применяется независимо от языка.

Answer 2

Я вообще не использую префиксы. Если я столкнусь с опасностью смешивания локальных переменных или параметров метода с членами класса, , тогда либо метод, либо класс будут слишком длинными и выиграют от разбиения .

Это (возможно) не только делает код более читабельным и несколько "беглым", но самое главное поощряет хорошо структурированные классы и методы . В конце концов, это сводится к совершенно другой проблеме, чем префикс или без префикса dillema.

ОБНОВЛЕНИЕ: ну, вкус и предпочтения меняются, не правда ли ... Сейчас я использую подчеркивание в качестве префикса для переменных-членов, поскольку это оказалось полезным для распознавания локальных и членских переменных в долгосрочной перспективе. Особенно новым членам команды иногда бывает трудно, когда их не так легко узнать.

Answer 3

Отсутствует. Раньше я использовал подчеркивание, но об этом говорили в проекте, где другим это не нравилось, и я его не пропустил. Приличная IDE или приличная память скажут вам, что является переменной-членом, а что нет. Один из разработчиков нашего проекта настаивает на том, чтобы поставить «это». перед каждой переменной-членом, и мы шутим над ним, когда работаем над областями кода, которые номинально являются «его».

Answer 4

Подчеркнуть только.

В моем случае я использую его, потому что это то, что сказано в документе по стандартам кодирования на моем рабочем месте. Тем не менее, я не вижу смысла добавлять m_ или какую-то ужасную венгерскую вещь в начале переменной. Минималистский «только подчеркивание» делает его читаемым.

Answer 5

Более важно быть последовательным, чем что-либо, поэтому выберите что-то, с чем вы и ваши товарищи по команде можете согласиться, и придерживайтесь этого. И если язык, на котором вы кодируете, имеет соглашение, вы должны стараться придерживаться его. Нет ничего более запутанного, чем кодовая база, которая непоследовательно следует правилу префиксов.

Для c ++ есть еще одна причина, по которой m_ предпочтительнее, кроме того факта, что _ иногда ставит префиксы перед ключевыми словами компилятора. М обозначает переменную-член. Это также дает вам возможность устранить неоднозначность между локальными и другими классами переменных, s_ для статических и g_ для глобальных (но, конечно, не используйте глобальные).

Что касается комментариев о том, что IDE всегда будет заботиться о вас, действительно ли IDE является единственным способом просмотра вашего кода? У вашего инструмента сравнения такой же уровень качества подсветки синтаксиса, как и у вашей IDE? А как насчет вашего инструмента управления версиями контроля версий? Вы никогда не переводите исходный файл в командную строку? Современные IDE являются фантастическими инструментами эффективности, но код должен легко читаться независимо от контекста, в котором вы его читаете.

Answer 6

Я предпочитаю использовать ключевое слово this. Это означает this.data или this->data вместо некоторых имен, зависящих от сообщества.

Потому что:

• с современными IDE, набрав this. popups intellinsense
• очевидно для всех, не зная определенных имен

Кстати, префиксные переменные с буквами для обозначения их типа устарели с хорошими IDE и напоминают мне об этом Статья Джоэла

Answer 7

Используя C #, я перешел от префикса 'm _' к , просто подчеркнув , так как 'm_' - наследие от C ++ .

Официальное руководство Microsoft рекомендует вам не использовать префиксы, а использовать верблюжий футляр для закрытых членов и паскаль-футляр для открытых членов . Проблема в том, что это противоречит другому руководству из того же источника, в котором говорится, что вы должны сделать весь код совместимым со всеми языками, используемыми в .NET . Например, VB.NET не делает различий между оболочками.

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

Обновление: я не думаю, что C # "это" - префикс помогает "Я". в VB, который по-прежнему будет видеть «Me.age» так же, как «Me.Age».

Answer 8

Мы используем m_, а затем слегка измененную нотацию Simonyi, как сказал Роб в предыдущем ответе. Таким образом, префикс кажется полезным, и m_ не слишком навязчив и его легко найти.

Почему нотация вообще? И почему бы просто не следовать (для .NET) рекомендациям Microsoft по обозначениям, которые основаны на регистре имен?

Сначала вопрос: как уже отмечалось, VB.NET безразличен к регистру. Так же как базы данных и (особенно) администраторы баз данных. Когда мне нужно сохранять прямые customerID и CustomerID (скажем, в C #), это причиняет боль моему мозгу. Таким образом, оболочка является формой обозначения, но не очень эффективной.

Префиксная нотация имеет значение несколькими способами:

1. Увеличивает понимание человеком кода без использования IDE. Как и в обзоре кода - который я до сих пор считаю самым простым на бумаге.
2. Когда-нибудь записывали T-SQL или другие хранимые в СУБД проки? Использование префиксной нотации в именах столбцов базы данных ДЕЙСТВИТЕЛЬНО полезно, особенно для тех из нас, кто любит использовать текстовые редакторы для такого рода вещей.

Короче говоря, префикс как форма записи полезен, поскольку все еще существуют среды разработки, в которых интеллектуальные IDE недоступны. Представьте, что IDE (программный инструмент) позволяет нам использовать некоторые ярлыки (например, типизацию intellisense), но не включает всю среду разработки.

IDE - это интегрированная среда разработки, точно так же, как автомобиль - это транспортная сеть: только одна часть более крупной системы. Я не хочу следовать соглашению о «машинах», например, оставаться на размеченных дорогах, когда иногда быстрее идти по пустыре. Полагаться на IDE для отслеживания ввода переменных - все равно, что использовать GPS автомобиля, чтобы пройти по свободному участку. Лучше иметь знания (хотя и неудобно иметь m_intCustomerID) в переносной форме, чем возвращаться к машине для каждого небольшого изменения курса.

Тем не менее, условное обозначение m_ или условное обозначение this доступны для чтения. Нам нравится m_, потому что он легко ищется и все еще позволяет типизированной переменной следовать за ним. Согласился, что обычное подчеркивание используется слишком многими другими действиями кода структуры.

Answer 9

Я добавляю переменные-члены к 'm', а параметры (в функции) к 'p'. Так что код будет выглядеть так:

class SomeClass {
    private int mCount;
    ...
    private void SomeFunction(string pVarName) {...}
}

Я считаю, что это быстро говорит вам об основной области действия любой переменной - если нет префикса, то это локально. Кроме того, при чтении функции вам не нужно думать о том, что передается и что является просто локальной переменной.

Answer 10

Это зависит от того, какой фреймворк я использую! Если я пишу код MFC, я использую m_ и венгерскую запись. Для других вещей (которые обычно бывают STL / Boost) я добавляю суффикс подчеркивания ко всем переменным-членам и не беспокоюсь о венгерской нотации.

Класс MFC

class CFoo  
{  
private:  
    int m_nAge;  
    CString m_strAddress;  
public:  
    int GetAge() const { return m_nAge; }  
    void SetAge(int n) { m_nAge = n; }  
    CString GetAddress() const { return m_strAddress;  
    void SetAddress(LPCTSTR lpsz) { m_strAddress = lpsz; }  
};

STL Класс

class foo  
{  
private:  
    int age_;  
    std::string address_;  
public:  
    int age() const { return age_; }  
    void age(int a) { age_ = a; }  
    std::string address() const { return address_; }  
    void address(const std::string& str) { address_ = str; }  
};

Теперь это может показаться немного странным - два разных стиля - но это работает для меня, и написание большого количества кода MFC, который не использует тот же стиль, что и сам MFC, выглядит просто уродливо.