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

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

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

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

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

С тех пор, как я начал программировать макросы Excel 97 с помощью IDE Office, мне никогда не требовалось соглашение об обсадке, чтобы рассказать мне, является ли какая-либо локальная переменная или свойство. Это потому, что я всегда использовал очень интуитивное соглашение об именах. Например, 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);
    }
}
19 голосов | спросил oscilatingcretin 19 J0000006Europe/Moscow 2013, 21:27:56

12 ответов


84

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

Employee employee;

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

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

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

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

ответил Karl Bielefeldt 19 J0000006Europe/Moscow 2013, 21:56:17
34

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

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

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

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

http://thecodelesscode.com/case/94

ответил Schleis 19 J0000006Europe/Moscow 2013, 21:32:39
24

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 выполняется только тогда, когда первый ---- +: = 4 =: + ----, это не так.

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

Имея строгий унифицированный стандарт, он упрощает чтение кода.

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

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

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

  • if,
  • [FK for Application: CreatedByApplicationId] или
  • [IX for SessionIPAddress: SessionId] литий>

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

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

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

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

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

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

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

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

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

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

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

ответил Arseni Mourzenko 19 J0000006Europe/Moscow 2013, 21:39:35
10

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

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

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

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

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

ответил tdammers 19 J0000006Europe/Moscow 2013, 23:17:13
9

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

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

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

ответил Jamie F 19 J0000006Europe/Moscow 2013, 23:45:20
7

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

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

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

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

ответил Adrian Schneider 19 J0000006Europe/Moscow 2013, 23:46:04
1

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

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

ответил N4TKD 19 J0000006Europe/Moscow 2013, 21:35:33
0

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

Линии становятся немного расплывчатыми при работе с такими вещами, как protected или Out или что-то в этом роде.

ответил John 20 J0000006Europe/Moscow 2013, 01:01:41
-2

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

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

ответил ayvango 20 J0000006Europe/Moscow 2013, 18:00:19
-2

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

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

Скорее всего, что происходит в вашем случае.

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

ответил ikh 13 J000000Saturday13 2013, 02:44:48
-3

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

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

ответил Filipe 22 FebruaryEurope/MoscowbMon, 22 Feb 2016 19:27:14 +0300000000pmMon, 22 Feb 2016 19:27:14 +030016 2016, 19:27:14
-4

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

ответил phkahler 20 J0000006Europe/Moscow 2013, 01:33:19

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132