Я использую 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 спасибо всем за быстрые ответы до сих пор
Ответы:
Я согласен, что это зависит от языка, который вы используете в некоторой степени; код имеет тенденцию выглядеть аккуратнее, когда имена ваших символов соответствуют тому же режиму форматирования, что и встроенные библиотеки языка и стандартные библиотеки.
Но там, где есть выбор, я предпочитаю подчеркивание верблюжьему случаю по одной простой причине: мне легче читать этот стиль. Вот пример: что вы считаете более читабельным? Этот:
или это:
Я считаю, что версию с подчеркиванием гораздо легче читать. Мой мозг может игнорировать подчеркивание гораздо легче , чем он может обнаружить границы нижнего / верхнего регистра в ГорбатыйРегистр, особенно там , где границы между символами , которые выглядят подобно другим глифов противном случае, или цифрами (
I/l
,O/0
,t/I
и т.д.). Например, эта логическая переменная хранит значение, указывающее, был ли построен Igloo с надлежащим разрешением на планирование (несомненно, это общий случай использования для всех нас):Я нахожу эту версию намного проще для чтения:
Возможно, даже хуже, чем трудно читаемое имя символа, это легко читаемое имя символа. Хорошие имена символов являются самодокументируемыми, что для меня означает, что вы должны быть в состоянии прочитать их и сразу понять их значение. (Я уверен, что мы все читаем распечатки кода в постели для удовольствия, но иногда мы тоже торопимся.) Я часто нахожу с именами символов в случае верблюда, что их легко неправильно прочитать и получить неправильное впечатление о семантика символа.
источник
Я думаю, что вы должны использовать соглашение об именах, принятое вашей платформой. underscore_case будет выглядеть странно в коде C #, как camelCase в Ruby =)
источник
Честно говоря, это не имеет значения, пока все в команде используют одну и ту же схему. Скорее всего, один или другой более естественны для вас, хотя реальная важность - это удобочитаемость кода в долгосрочной перспективе, и тогда крайне важно, чтобы все придерживались одинаковых правил именования.
источник
На основании ответа ответ Джона Исаака:
Я решил провести небольшое исследование и нашел эту статью . Что наука должна сказать по этому вопросу?
В своем блоге на эту тему я рецензирую научную статью и делаю следующий вывод.
Только медлительность верблюжьего случая (2) действительно важна для программирования, игнорируя другие моменты как несущественные из-за современных IDE и большинства пользователей camelCase в исследовании. Обсуждение (вместе с опросом) можно найти в блоге.
Мне любопытно, как эта статья может изменить свое мнение. :)
источник
Скопируйте самых умных парней
В случае языков программирования скопируйте стиль разработчика языка.
Например, я кодирую C точно так же, как это делается в K & R.
Затем, когда кто-нибудь пытается начать скучную беседу в стиле кодирования, я могу сказать им: «Принесите это Деннису Ритчу и дайте мне знать, что он говорит».
источник
if (...) {
сэкономить! В наши дни появляется больше места на экране - будут ли отличаться K & R, если они будут написаны сегодня с IDE с высоким разрешением GUI и несколькими настройками монитора?В общем, я предпочитаю CamelCase. Однако это связано с тем, что большую часть моей карьеры я работаю в языках и средах, где руководства по стилю обычно рекомендуют camelCase. (Java, ECMAScript, C ++). Вы, будучи человеком PHP, скорее всего, будете иметь противоположное предпочтение.
Тем не менее, когда вы выходите за пределы threeOrFourWords или используете инициализмы, такие как XMLForExample, он перестает быть таким читабельным.
Вот почему Emacs дает нам режим очков.
источник
верблюжьего
Это одно из немногих мест, где я всегда буду выбирать «способность к типу» вместо читабельности. CamelCase проще набирать, и приятность моих пальцев выигрывает от небольшого увеличения читабельности для меня.
конечно, предполагая, что проект не основан на существующей кодовой базе с другим стандартом.
источник
Это интересный вопрос, я думал об этом много раз. Но нет определенного ответа, я думаю.
Следуя «культурным» конвенциям, это хороший выбор. «Культурный» в данном случае означает соглашения, установленные в команде / компании, и они в основном несут также соглашения о языке / платформе. Это помогает другим легко читать / использовать ваш код и не требует дополнительных усилий и времени, чтобы разобраться в вашем коде.
Иногда интересно нарушить принятые обозначения. Один из моих небольших проектов (на Python) я использовал
underscored_names
для служебных функций / «защищенных» методов и в стиле JavamethodNames
для методов. Моя команда была счастлива с этим :)источник
Зависит от языка программирования.
Я рассматриваю возможность использования кейса в одной лодке, использовать ли венгерские обозначения:
источник
XMLHttpRequest
<- Я ненавижу это имя со страстью.Обе!
Я много занимаюсь разработкой в CakePHP, и я использую либо,
CamelCase
либо$underscored_vars
, следующим образом (даже вне CakePHP Projects):/lowercased_underscored.php
типичные, но стоит упомянуть.class CamelCase extends ParentObject
. Обратите внимание, что при использованииCamelCase
начальный символ не строчный. Я нахожуcamelCase
выглядеть очень странно.$are_variables_underscored === TRUE;
$CamelCase = new CamelCase();
$collection['underscored_keys'];
ALL_CAPS_AND_UNDERSCORED
.$CamelCase->foo_method_underscored();
CamelCase::just_like_regular_methods();
источник
Я лично предпочитаю,
underscore_case
потому что нахожу это более читабельным, но согласен с другими авторами, которые указывают, что согласованность с существующей кодовой базой намного важнее.Тем не менее, у меня есть контрпример для тех, кто говорит «соблюдайте соглашение вашего языка и его библиотек».
В прошлом мы писали код C на Windows , используя
underscore_case
, и называетсяPascalCase
Win32 функции:Визуальное различие между именами наших функций и именами функций Microsoft было скорее помощью, чем помехой, как это ясно показало, когда код входил в «системную страну».
Кроме того, мне удалось изменить правила подсветки синтаксиса моего редактора, чтобы они отображались разными цветами, что дало дополнительные визуальные подсказки при попытке понять незнакомые фрагменты кода (или даже мои собственные).
источник
Мне действительно нравятся просто нормальные черточки Дилана, поскольку их легко набирать и легко читать.
подобно
Но я думаю, что этот язык довольно неясен, это не по теме ... :(
источник
Меня учили использовать camelCase в университете. За последние несколько лет я использовал несколько различных соглашений, но предпочитаю CamelCase, а не все остальное. Я думаю, что помню, что читал где-то, что camelCase на самом деле легче всего читать и понимать.
источник
Как уже упоминало большинство людей - используйте существующий стандарт. Если это новый проект, используйте стандарт для языка и структур, которые вы будете использовать.
И не смущайтесь, речь идет не о читабельности (которая субъективна), а о том, чтобы быть последовательным и профессиональным. Любой, кто работал в кодовой базе с многочисленными «стандартами», поймет.
источник
Я иногда использую смесь: module_FunctionName. Все (нестатические) функции в моих модулях начинаются с аббревиатуры модуля.
Например, функция для отправки содержимого буфера на шину I2C:
Альтернатива
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.
источник
Motor1_Start()
,Motor2_Start()
,Motor1_Stop()
иMotor2_Stop()
есть отношения , которые могли бы быть менее ясно , без подчеркивания.Лично я предпочитаю camelCase, но в некоторых шрифтах подчеркивание легче читать.
Я хотел бы предложить, что если вам нужно использовать префиксы для дифференциации наборов переменных, вы должны использовать язык, который позволяет вам создавать пространства имен или объекты или что-то для хранения этой информации.
Точно так же, если вам нужно различать типы, почему бы не использовать язык, который позволяет им?
Если у вас есть это прямое выражение, и вы не просто используете имя в качестве метаданных, то у вас не будет достаточно длинных имен, поэтому очень важно, предпочитаете ли вы это дополнительное нажатие клавиши или нет.
источник
Сначала я согласен с dafmetal. Очень важно, чтобы вы не смешивали разные стили программирования. Выполнение этого в одном и том же файле - худшее, что вы можете сделать, ИМХО. В разных файлах это отвлекает, но не смертельно.
Следующее, что вам нужно сделать, это определить правила именования, которые популярны для языка, на котором вы пишете. Мой код на C ++ для instnace, очевидно, будет отличаться от кода для Python (PEP8 - хорошее руководство здесь)
Вы также можете использовать разные соглашения об именах для ссылки на разные вещи, поскольку вы, вероятно, используете UPPER_CASE для констант (это, конечно, относится только к определенным языкам), вы можете использовать this_style для имен локальных переменных, тогда как вы используете camelCase для instance / member переменные. Это может не понадобиться, когда у вас есть такие вещи, как
self
илиthis
однако.Обновить
На самом деле нет преимуществ для одного над другим. Это очень субъективный вопрос, и если он будет согласован, это не изменится. Всегда есть эти религиозные войны об этих маленьких вещах. Но как только вы привыкнете к тому или иному, дискуссии кажутся совершенно излишними.
Цитирую Алекса Мартелли по очень похожему вопросу:
Источник
Если вы лидер команды, вы просто идете с одним. Так как одно не имеет никаких преимуществ перед другим, вы можете просто бросить кости или выбрать то, что вам больше нравится.
источник
Несколько лет назад я читал, что программисты, которые не говорят по-английски как на родном языке, склонны находить подчеркивание, которое проще для понимания этого случая с верблюдом, но я не могу найти ссылку, и я понятия не имею, правда ли это.
источник
Для языков программирования, которые я использовал, таких как Java, Python, C ++, я выбрал четкий формат:
Это позволяет мне сразу понять, с чем я имею дело. Я обнаружил, что это полезно поддерживать для себя, и за кем-то, кто читает код, должно быть легко следить. Я думаю, что, как другие упоминали, последовательность важнее всего. Поэтому я нахожу, что мой формат достаточно прост, чтобы поддерживать его, в то же время обеспечивая четкие различия между типами имен. Я мог бы представить 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!» (не всегда возможно, хотя).
В конце концов, не имеет значения, какой стиль вы используете, потому что компилятору / интерпретатору все равно. Важно то, что название полезно:
Три разных стиля, но вы точно знаете, что делает каждый.
источник
Может показаться глупым, но мне не нравятся подчеркивания, потому что подчеркивание тонкое, скрывается в многострочном тексте, и я скучаю по нему. Кроме того, в некоторых (многих) текстовых редакторах и / или средах разработки, если дважды щелкнуть имя токена, чтобы выделить его, чтобы скопировать или перетащить его, система не выделит весь токен, а только выделит одну часть. токена, между соседними подчеркиваниями. Это сводит меня с ума.
источник
Я предпочитаю предпочитать camelCase по глупой причине, по которой я делаю большую часть своей разработки в Eclipse (для Java, PHP и JavaScript), и когда я Ctrl+ ←или Ctrl+ →через слова, он фактически останавливается у границ camelCase.
myIntVariable
То есть: будет восприниматься Eclipse как 3 слова при Ctrl+ ← →сквозь него.Я знаю, что это странная причуда, но я предпочитаю иметь возможность редактировать средние слова в названии camelCase.
источник