Какое хорошее соглашение об именах для больших переменных функций?

Question

Вы можете иметь разные соглашения об именах для членов класса, статических объектов, глобальных объектов и структур. Некоторые из них приведены ниже.

_member
m_member

или в случае Java, использование this.member.

Но есть ли хороший метод или соглашение об именах для области видимости переменных функции, которое передает, когда одна переменная имеет полный объем функции или область короткого срока службы?

void MyFunction()
{
  int functionScopeVariable;

  if(true)
  {
    //no need for function variable scope naming convention
  }
}

Answer 1

Я действительно рекомендую делегировать эту задачу в IDE / редакторе, который вы используете.

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

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

Итак, мое предложение: используйте значимые имена без префикса или суффикса.

Answer 2

Один из способов - следовать указаниям: чем больше область действия переменной, тем длиннее имя. Таким образом, глобальные переменные получают длинные описательные имена, а ограниченные областью действия, такие как переменная индекса цикла, могут быть как маленькие буквы.

Answer 3

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

Answer 4

Руководство по MSFT и другим руководствам по стилю для частных полей экземпляров: _memberName (запись с верблюжьим регистром с префиксом "_"). Это также соглашение, используемое в исходном коде многих недавних учебных пособий Microsoft.

Я использую его, потому что он короче, а не венгерский, и R # поддерживает его как правило по умолчанию для частных полей экземпляра.

Мне также это нравится, потому что оно как бы скрывает приватные поля от Intellisense, как и должно быть, так как вы должны предпочесть доступ к своим публичным членам в первую очередь. Если я хочу получить доступ к свойству Name и начинаю набирать "Na", первым предложением будет свойство общего экземпляра Pascal-cased. В тех редких случаях, когда я хочу получить доступ к приватному полю напрямую, это заставляет меня сознательно принять решение начать печатать "_", после чего я получаю полный список своих приватных полей во всплывающем окне Intellisense.

Я также видел руководство, в котором говорится, что это должно быть _MemberName, если оно является вспомогательным полем для открытого свойства с именем MemberName (запись Pascal в префиксе с префиксом "_"). Мне лично это не нравится, потому что я думаю, что прописной M является избыточным, добавляет ненужные нажатия клавиш и не добавляет никакой дополнительной информации.

Answer 5

Существует аргумент, что у вас не должно быть «функций большого объема», поэтому не должно быть проблем с именованием - просто используйте соглашения по именованию переменных «функция малого объема».

Answer 6

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

Answer 7

Я предпочитаю быть простым, я использую:

 m_varname - Class member variables
 g_varname - Global variables

Answer 8

Полагаю, все в порядке, если оно передает смысл его использования.

Answer 9

На самом деле все сводится к тому, что предлагают рекомендации по стилю языка, если таковые имеются.

Answer 10

Мы склонны использовать префикс l_ в наших функциях для "local". И это сработало довольно хорошо.