В чем причина использования строчных букв для первого слова в локальной переменной (например, employeeCount, firstName)

Я получаю много критики от других программистов из-за того, что я использую полный надлежащий регистр для всех моих переменных. Например, ваш типичный программист будет использовать employeeCountдля имени переменной, но я использую EmployeeCount. Я использую полный надлежащий регистр для всего , будь то метод void, метод возврата, переменная, свойство или константа. Я даже следую этому соглашению в Javascript. Последний действительно шуршит людьми.

Типичная причина, по которой я не должен следовать этому «нестандартному» соглашению о оболочках, заключается в том, что для свойств и методов void следует зарезервировать полный надлежащий регистр. Локальная переменная и методы, которые возвращают значение, должны иметь первое слово в нижнем регистре, как int employeeCount = getEmployeeCount().

Однако я не понимаю, почему.

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

С тех пор, как я начал программировать макросы Excel 97 с помощью Office IDE, я никогда не нуждался в соглашении о регистре, чтобы сказать мне, является ли что-то локальной переменной или свойством. Это потому, что я всегда использовал очень интуитивное соглашение об именах. Например, GetNuggetCount()ясно предлагает метод, который идет куда-то и получает счет всех самородков. SetNuggetCount(x)предполагает, что вы присваиваете новое значение количеству слепков. NuggetCountсамо по себе предлагает свойство или локальную переменную, которая просто содержит значение. На этот последний может возникнуть соблазн сказать: «Ага! Вот в чем вопрос. Свойство или переменная? ЧТО ЭТО?» На это я бы ответил: «Это действительно имеет значение?»

Итак, вот tl; dr ;: Каковы объективные, логические, не произвольные причины использовать строчные буквы для первого слова в вашей переменной или методе возврата?

Изменить: для MainMa

Замените этот код первым примером кода в своем ответе и посмотрите, насколько хорошо ваш аргумент выдерживает:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

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

Employee employee;

Некоторые языки даже применяют эту заглавную букву. Это предотвращает использование раздражающих имен переменных , как MyEmployee, CurrentEmployee, EmployeeVarи т.д. Вы всегда можете сказать , если что - то тип или переменный, только от капитализации. Это предотвращает путаницу в ситуациях, таких как:

employee.function(); // instance method
Employee.function(); // static method

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

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

Там нет ни одного. Это то, что делает большинство людей, поэтому оно стало стандартом, потому что это то, что делают все. Много литературы следует этой конвенции, поэтому люди приобрели эту привычку.

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

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

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

http://thecodelesscode.com/case/94

1. Почему стандарт существует?

В конце концов, не лучше ли позволить каждому писать код в соответствии с личными предпочтениями и перестать говорить о том, какой стандарт лучше?

Дело в том, что, когда вы привыкли к одному стилю, труднее читать код, который использует другой стиль. Ваш мозг тратит больше времени, пытаясь понять соглашение (если оно есть) вместо понимания того, что делает код.

Что является более читабельным между этими двумя частями кода?

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

или:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

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

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

Обладая строгим единообразным стандартом, он облегчает чтение кода.

2. Почему их стандарт лучше, чем тот, который я изобрел прямо сейчас?

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

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

• [FK for Application: CreatedByApplicationId],
• [IX for SessionIPAddress: SessionId] или
• [PK for RoleOfPassword: RoleId, PasswordId],

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

• Когда я найму DBA, он будет вынужден изучить новое соглашение, вместо того, чтобы начинать свою работу прямо сейчас,

• Я не могу поделиться частями кода в Интернете как есть: эти странно выглядящие имена будут мешать людям, которые будут читать мой код,

• Если я возьму код извне, чтобы использовать его по-своему, я был бы вынужден изменить имена, чтобы сделать его единообразным,

• Если однажды я решу использовать какой-то известный стандарт, я буду вынужден пойти и изменить каждое из нескольких сотен имен.

3. Итак, как насчет капитализации?

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

Если вы рассматриваете C #, эта логика достаточно последовательна.

Если вы рассматриваете Java, методы начинаются с маленьких букв, которые не следуют логике.

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

В JavaScript функции начинаются с маленькой буквы, если они не требуют newперед ними. Разве не лучше? Может быть. Дело в том, что в течение многих лет разработчики JavaScript использовали этот стандарт, а не наоборот. Переписать каждую книгу и заставить каждого разработчика изменить стиль сейчас будет немного сложно.

Технически это не имеет значения (или, по крайней мере, в большинстве языков это не имеет значения).

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

Не потому, что они лучшие, а потому, что они - то, что все остальные используют; если вы придерживаетесь стандарта, ваш код будет соответствовать большей части другого кода, который вы в конечном итоге будете использовать - библиотеки, код товарищей по команде, встроенные языки. Последовательное именование является одним из мощных инструментов повышения производительности, поскольку оно означает, что когда вы угадываете название чего-либо, вы обычно угадываете правильно. Это file.SaveTo(), File.saveTo(), file.save_to(), FILE.save_to()? Соглашение об именах скажет вам.

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

Только один пример: в C # типы и переменные живут в отдельных пространствах имен; компилятор достаточно умен, чтобы понять разницу. В C, однако, оба вида имен имеют общее пространство имен, поэтому нельзя иметь тип и переменную с одинаковым именем в одной и той же области видимости. Из-за этого C нуждается в соглашении об именовании, которое отличает типы от переменных, а C # - нет.

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

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

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

Это больше похоже на вопрос об условностях, а не о вашем конкретном соглашении.

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

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

Что касается вашего фактического соглашения, CapitalCamelCase обычно зарезервирован для имен классов (или в Javascript, конструкторы). Если я увижу заглавную переменную, образованное предположение потребует, чтобы мне понадобилось создать его экземпляр, чтобы использовать его. Если это не так, я разозлюсь, что код не соответствует стандартам сообщества. Даже с большинством других языков все, кто смотрит на него впервые, мгновенно вводятся в заблуждение. Я хочу, чтобы код был очевидным, а не вводящим в заблуждение.

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

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

Поскольку другие не сказали никакой реальной причины, за исключением того, чтобы свалить соглашение об именовании. Если вы можете собрать всю свою команду на одной странице, вы, вероятно, сэкономите себе время. Например, лично я начал заниматься стандартами кодирования, которые вошли в это, и мы использовали camelCase для всех частных переменных, а также для объектов, передаваемых Val, в то время как мы использовали PascalCase для общедоступных и передаваемых в Ref.

Линии становятся немного размытыми, когда имеешь дело с такими вещами, как защищенный или Out или чем-то.

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

Символы в нижнем и верхнем регистре имеют большие семантические различия в Haskell, также они немного отличаются в Scala, и я использовал оба из них. Другие языки, которые я использую, не делают различий между этими двумя типами идентификаторов, но держать мысли в том, как Хаскелл воспринимает идентификаторы, для меня гораздо проще, чем разбивать мои мысли на разные языки.

Для меня все сводится к ожиданиям.

Когда я читаю большую часть кода, я ожидаю, что все, что начинается с a, lowerCaseбудет локальной переменной или функцией (в C # это будет просто переменная). Если я вижу локальную переменную вProperCase , я, скорее всего, на некоторое время запутаюсь и запутаюсь, думая, что это либо имя класса, либо свойство, либо что-то еще. Это заставило бы меня перечитать код и раздражало бы меня.

Это, вероятно, то, что происходит в вашем случае.

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

Нижний регистр должен использоваться для локальных переменных для простоты ввода (скорость / без клавиши Shift). Верхний регистр используется для улучшения читаемости, разделяя слова внутри имени. Код с именами локальных переменных, состоящими из одного слова (которые должны быть общими), быстро и легко вводится. Использование верхнего регистра для каждого нового слова в имени также быстрее (и меньше места), чем использование подчеркивания, которое добавляет другой символ - это также называется верблюжьим регистром.

Я согласен с ОП здесь. CamelCase просто выглядит неправильно. Я также согласен с тем фактом, что это стандарт, и мы должны придерживаться того же стандарта, или какой смысл иметь стандарт. Также имеет смысл использовать PascalCaps для методов и т. Д., А camelCase для собственных переменных и т. Д. Как способ дифференциации, когда не используется IDE, которая окрашивает методы для вас.

Чтобы обойти это, я всегда добавляю к именам своего объекта тип объекта. Поэтому, если это строковая переменная, я вызываю strMyVariable. Если это какой-то объект, я называю его objMyObject и т. Д. Таким образом, он начинается с маленьких заглавных букв в соответствии со стандартом и выглядит правильно.