Соглашения об именах: camelCase или underscore_case? что вы думаете об этом? [закрыто]

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

Теперь все на работе используют camelCase, потому что (как они говорят) код выглядит более элегантно.

Что вы думаете о camelCase или underscore_case

пожалуйста извините мой плохой английский

редактировать

Некоторое обновление сначала:

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

• Я использую CamelCase так же, как и все остальные в команде (как большинство из вас рекомендуют)

• мы используем Zend Framework, который также рекомендует camelCase

Некоторые примеры (связанные с PHP):

• Платформа Codeigniter рекомендует underscore_case, и, честно говоря, код легче читать.

• ZF рекомендует camelCase, и я не единственный, кто думает, что код ZF немного сложнее выполнить.

Так что мой вопрос будет перефразирован:

Давайте возьмем случай, когда у вас есть платформа Foo, которая не рекомендует никаких соглашений об именах, и лидер команды выбирает один из них. Вы тот лидер команды, почему вы выбрали camelCase или почему underscore_case?

ps спасибо всем за быстрые ответы до сих пор

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

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

aRatherLongSymbolName

или это:

a_rather_long_symbol_name

Я считаю, что версию с подчеркиванием гораздо легче читать. Мой мозг может игнорировать подчеркивание гораздо легче , чем он может обнаружить границы нижнего / верхнего регистра в ГорбатыйРегистр, особенно там , где границы между символами , которые выглядят подобно другим глифов противном случае, или цифрами ( I/l, O/0, t/Iи т.д.). Например, эта логическая переменная хранит значение, указывающее, был ли построен Igloo с надлежащим разрешением на планирование (несомненно, это общий случай использования для всех нас):

isIllicitIgloo

Я нахожу эту версию намного проще для чтения:

is_illicit_igloo

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

Я думаю, что вы должны использовать соглашение об именах, принятое вашей платформой. underscore_case будет выглядеть странно в коде C #, как camelCase в Ruby =)

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

На основании ответа ответ Джона Исаака:

«Честно говоря код легче читать» Мнение или факт?

Я решил провести небольшое исследование и нашел эту статью . Что наука должна сказать по этому вопросу?

1. Верблюжий корпус имеет большую вероятность правильности, чем подчеркивание. (коэффициент выше на 51,5%)
2. В среднем дело верблюда занимало 0,42 секунды дольше , что на 13,5% больше.
3. Обучение не оказывает статистически значимого влияния на то, как стиль влияет на правильность.
4. Те, у кого больше подготовки, быстрее разбирались в идентификаторах в стиле верблюдов.
5. Обучение в одном стиле негативно влияет на время поиска для других стилей.

В своем блоге на эту тему я рецензирую научную статью и делаю следующий вывод.

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

Мне любопытно, как эта статья может изменить свое мнение. :)

Скопируйте самых умных парней

В случае языков программирования скопируйте стиль разработчика языка.

Например, я кодирую C точно так же, как это делается в K & R.

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

В общем, я предпочитаю CamelCase. Однако это связано с тем, что большую часть моей карьеры я работаю в языках и средах, где руководства по стилю обычно рекомендуют camelCase. (Java, ECMAScript, C ++). Вы, будучи человеком PHP, скорее всего, будете иметь противоположное предпочтение.

Тем не менее, когда вы выходите за пределы threeOrFourWords или используете инициализмы, такие как XMLForExample, он перестает быть таким читабельным.

Вот почему Emacs дает нам режим очков.

верблюжьего

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

конечно, предполагая, что проект не основан на существующей кодовой базе с другим стандартом.

Это интересный вопрос, я думал об этом много раз. Но нет определенного ответа, я думаю.

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

Иногда интересно нарушить принятые обозначения. Один из моих небольших проектов (на Python) я использовал underscored_namesдля служебных функций / «защищенных» методов и в стиле Java methodNamesдля методов. Моя команда была счастлива с этим :)

Зависит от языка программирования.

Я рассматриваю возможность использования кейса в одной лодке, использовать ли венгерские обозначения:

• Python: underscore_case, нет венгерской нотации
• C ++: camelCase, венгерская нотация

Обе!

Я много занимаюсь разработкой в ​​CakePHP, и я использую либо, CamelCaseлибо $underscored_vars, следующим образом (даже вне CakePHP Projects):

1. имена файлов - /lowercased_underscored.phpтипичные, но стоит упомянуть.
2. классы - class CamelCase extends ParentObject. Обратите внимание, что при использовании CamelCaseначальный символ не строчный. Я нахожу camelCaseвыглядеть очень странно.
3. переменные -$are_variables_underscored === TRUE;
4. переменные, которые содержат экземпляры -$CamelCase = new CamelCase();
5. ключи массива -$collection['underscored_keys'];
6. константы - я думаю, что каждый может согласиться, что константы должны быть ALL_CAPS_AND_UNDERSCORED.
7. методы -$CamelCase->foo_method_underscored();
8. статические методы -CamelCase::just_like_regular_methods();

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

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

В прошлом мы писали код C на Windows , используя underscore_case, и называется PascalCaseWin32 функции:

if (one_of_our_conditions_is_true())
{
    call_one_of_our_functions();
    CallSystemFunction();
}

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

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

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

подобно

result-code := write-buffer(file-stream, some-string)

Но я думаю, что этот язык довольно неясен, это не по теме ... :(

Меня учили использовать camelCase в университете. За последние несколько лет я использовал несколько различных соглашений, но предпочитаю CamelCase, а не все остальное. Я думаю, что помню, что читал где-то, что camelCase на самом деле легче всего читать и понимать.

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

И не смущайтесь, речь идет не о читабельности (которая субъективна), а о том, чтобы быть последовательным и профессиональным. Любой, кто работал в кодовой базе с многочисленными «стандартами», поймет.

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

Например, функция для отправки содержимого буфера на шину I2C:

i2c_BufferSend()

Альтернатива i2c_buffer_sendне показывает достаточно большое разделение между префиксом и именем функции. i2cBufferSendслишком сильно смешивается в префиксе (в этом модуле довольно много функций I2C).

i2c_Buffer_send возможно, была альтернатива, хотя.

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

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

Лично я предпочитаю camelCase, но в некоторых шрифтах подчеркивание легче читать.

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

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

Точно так же, если вам нужно различать типы, почему бы не использовать язык, который позволяет им?

var intThingy = 7; // :(

int thingy = 7;    // :)

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

Сначала я согласен с dafmetal. Очень важно, чтобы вы не смешивали разные стили программирования. Выполнение этого в одном и том же файле - худшее, что вы можете сделать, ИМХО. В разных файлах это отвлекает, но не смертельно.

Следующее, что вам нужно сделать, это определить правила именования, которые популярны для языка, на котором вы пишете. Мой код на C ++ для instnace, очевидно, будет отличаться от кода для Python (PEP8 - хорошее руководство здесь)

Вы также можете использовать разные соглашения об именах для ссылки на разные вещи, поскольку вы, вероятно, используете UPPER_CASE для констант (это, конечно, относится только к определенным языкам), вы можете использовать this_style для имен локальных переменных, тогда как вы используете camelCase для instance / member переменные. Это может не понадобиться, когда у вас есть такие вещи, как selfили thisоднако.

Обновить

Давайте рассмотрим случай, когда у вас есть платформа, на которой ведьма не рекомендует никаких соглашений об именах, и лидер команды выбирает один из них. Вы тот лидер команды, почему вы выбрали camelCase или почему underscore_case.

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

Цитирую Алекса Мартелли по очень похожему вопросу:

Конечно, в Ruby мне надоело набирать глупый «конец» в конце каждого блока (а не просто делать отступы) - но потом я стараюсь не вводить одинаково глупый «:», который требует Python при начало каждого блока, так что почти мыть :-). Другие различия в синтаксисе, такие как «@foo» и «self.foo», или более высокая значимость падежа в Ruby против Python, для меня практически не имеют значения.

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

Источник

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

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

Для языков программирования, которые я использовал, таких как Java, Python, C ++, я выбрал четкий формат:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

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

Я также счел полезным быть строгим и называть вещи в PascalCase, такие как анализатор HTML, как HtmlParser вместо HTMLParser или HTMLparser. Потому что я считаю, что легче запомнить строгое правило и держать границы слов более четкими (к сожалению, это требует неправильных написаний, таких как HTML или SQL). Аналогично с camelCase, htmlParserMethod вместо HTMLParserMethod или HTMLparserMethod.

ОБНОВЛЕНИЕ :

С тех пор я нашел применение для расширения этих правил, чтобы включить частные переменные. - _private_variable_names_are_prefixed_with_an_underscore - _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

В Java это означает, что частные поля по определению находятся в другом пространстве имен, чем локальные переменные, что означает, что вы можете пропустить this.частные поля. В других форматах я видел префикс « m», но эти форматы также используют camelCase для имен переменных. Это также позволяет мне сделать различие между полями , которые должны быть доступны только внутри класса (и делает его супер ясно , когда это происходит за пределами класса object._field_xвыделяется).

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

Итак, основной аргумент для соглашения, который я предполагаю, заключается в том, что вы заранее знаете, что такое формат имени функции / переменной, и вам не нужно его искать - это LoadXMLFile, loadXMLFile, LoadXmlFile, load_xml_file? Теперь я бы против этого аргумента сказал: «Получите IDE, которая поддерживает автозаполнение в стиле intellisense!» (не всегда возможно, хотя).

В конце концов, не имеет значения, какой стиль вы используете, потому что компилятору / интерпретатору все равно. Важно то, что название полезно:

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

Три разных стиля, но вы точно знаете, что делает каждый.

Может показаться глупым, но мне не нравятся подчеркивания, потому что подчеркивание тонкое, скрывается в многострочном тексте, и я скучаю по нему. Кроме того, в некоторых (многих) текстовых редакторах и / или средах разработки, если дважды щелкнуть имя токена, чтобы выделить его, чтобы скопировать или перетащить его, система не выделит весь токен, а только выделит одну часть. токена, между соседними подчеркиваниями. Это сводит меня с ума.

Я предпочитаю предпочитать camelCase по глупой причине, по которой я делаю большую часть своей разработки в Eclipse (для Java, PHP и JavaScript), и когда я Ctrl+ ←или Ctrl+ →через слова, он фактически останавливается у границ camelCase.

myIntVariableТо есть: будет восприниматься Eclipse как 3 слова при Ctrl+ ← →сквозь него.

Я знаю, что это странная причуда, но я предпочитаю иметь возможность редактировать средние слова в названии camelCase.