Какое хорошее соглашение об именах для переменных функций большого объема?
У вас могут быть разные соглашения об именах для членов класса, статических объектов, глобальных объектов и структур. Некоторые из их примеров приведены ниже.
_member
m_member
или, в случае Java, использование this.member.
Но есть ли какой-либо хороший метод или соглашение об именах для области функциональных переменных, которое передает, когда одна переменная имеет полную область действия или короткую область действия?
void MyFunction()
{
int functionScopeVariable;
if (true)
{
//no need for function variable scope naming convention
}
}
Ответы 10
Мы склонны использовать префикс l_ в наших функциях для слова «локальный». И это сработало очень хорошо.
Так вы имеете в виду, что с переменными, которые имеют область действия для параметров функции примеров, нужно добавлять "l_" в начале их. Просто для ясности?
Один из способов - следовать руководству, согласно которому чем больше объем переменной, тем длиннее имя. Таким образом, глобальные переменные получают длинные описательные имена, в то время как вещи с ограниченным объемом, такие как индексная переменная цикла, могут быть всего лишь отдельными буквами.
Я делаю это естественно и даже не замечал этого до сих пор. +1
Я использую префиксы или специальные соглашения об именах для глобальных, статических переменных и переменных-членов, поэтому мне не нужно использовать префиксы для локальных переменных. Я предпочитаю использовать короткие имена локальных переменных, особенно для переменных цикла.
На самом деле все сводится к тому, что предлагают рекомендации по стилю для языка, если таковые имеются.
Есть аргумент, что у вас не должно быть «функций с большой областью видимости», поэтому не должно быть проблем с именованием - просто используйте соглашения об именах переменных «функции с малой областью видимости».
Я полагаю, что все в порядке, если оно передает смысл его использования.
Я предпочитаю, чтобы это было просто, я использую:
m_varname - Class member variables
g_varname - Global variables
Да, я понимаю. Но как насчет переменных функций, которые либо имеют полную область действия, либо ограниченную область действия в операторе if.
Я не делаю различий между ними, и у меня никогда не бывает одного и того же имени var, используемого с областью функции и ограниченной областью, это имеет тенденцию сбивать с толку.
Я действительно рекомендую делегировать эту задачу IDE / редактору, который вы используете.
Нет, на самом деле я не говорю об именах переменных, это лучше всего делать человеком. Но основная задача таких стратегий именования - показать вам, какой тип переменной представляет любое одно имя.
Практически каждая достойная IDE может определять разные стили (цвета, шрифты, типы шрифтов и т. д.) Для разных типов переменных (член экземпляра, статический член, аргумент, локальная переменная и т. д.), Поэтому позволяя IDE сообщать вам, что Тип переменной фактически освобождает вас от необходимости каждый раз вводить эти (в противном случае бесполезные) пре- или суффиксы.
Итак, мое предложение: используйте значимые имена без префикса или суффикса.
Вероятно, что некоторые инструменты (ваша VCS, diffs, ваша система обзора кода) не имеют всех ваших причудливых функций IDE, поэтому также сравните это с затратами на размещение информации об области действия в ваших именах переменных. Кроме того, чем больше команда, тем больше вероятность, что кто-то использует Vim (хотя они, вероятно, привыкли работать с тем, что им бросает жизнь :)
Руководство MSFT и других руководств по стилю для полей частных экземпляров - _memberName (обозначение верблюжьего регистра с префиксом _"). Это также соглашение, используемое в исходном коде многих недавних руководств Microsoft.
Я использую его, потому что он короче, а не венгерский, и R # поддерживает его как правило по умолчанию для полей частных экземпляров.
Мне также это нравится, потому что он как бы скрывает частные поля от Intellisense, как и должно быть, поскольку вы должны сначала получить доступ к своим общедоступным членам. Если я хочу получить доступ к свойству Name и начинаю набирать «Na», первое предложение - это имя общедоступного свойства экземпляра на основе Паскаля. В тех редких случаях, когда я хочу получить доступ к частному полю напрямую, это вынуждает меня принять сознательное решение начать вводить «_», после чего я получаю полный список моих частных полей во всплывающем окне Intellisense.
Я также видел руководство, в котором говорится, что это должно быть _MemberName, если это вспомогательное поле для общедоступного свойства с именем MemberName (нотация Pascal с префиксом «_»). Мне лично это не нравится, потому что я думаю, что заглавная M избыточна, добавляет ненужные нажатия клавиш и не добавляет никакой дополнительной информации.
Я использую то же соглашение, что и для учеников класса. IDE должна позаботиться о поиске вашего объявления. Если функция настолько велика и сбивает с толку, что становится проблемой, необходимо решить проблему с gretaer.
Да, поэтому для вашего примера, если бы область видимости переменной была только с MyFunction (), наше соглашение заключалось бы в том, чтобы называть ваш var l_functionScopeVar ... Я заметил, что это упрощает чтение чужого код с префиксами, даже если они просто локальные временные переменные ...