0,0
рейтинг
2 февраля 2011 в 18:58

Разработка → camelCase против under_score перевод

В настоящее время существует много стандартов наименования переменных, но два из них являются наиболее популярными среди программистов: это camel case («Верблюжья» нотация) и underscore (именование переменных с использованием символа нижнего подчеркивания в качестве разделителя). Кто-то может возразить, что существуют и другие популярные стандарты, но в рамках данной статьи мы сравним эти два, и узнаем у программистов — какого стандарта придерживаются они. Конечно, некоторые программисты связаны рамками стандартов кодирования языка или фреймворка, который они используют, но мы постараемся сделать независимое сравнение.


Стандарт наименований с использованием нижнего подчеркивания заключается в том, что все слова записываются строчными буквами и разделяются символом нижнего подчеркивания (_). Обычно этот стандарт используется в названиях функций и переменных, а для названий классов, структур, интерфейсов используется стандарт Pascal (прим. переводчика: почему-то в статье про него ничего не говорится, но как я нашел в википедии Pascal style это UpperCamelCase, когда первое слово начинается с прописной буквы, пруф). Underscore изначально использовался программистами С, и потом был использован разработчиками С++ при наименовании ключевых слов и в библиотеке STL, а затем и в Boost, из-за чего данный стандарт приобрел большую популярность среди программистов С++, но не стал доминирующим. Также данный стандарт используется в названиях стандартных функций PHP, и является очень популярным среди PHP-программистов. Говорят, что в Руби тоже используется нижнее подчеркивание.

С другой стороны, верблюжья нотация является стандартом в языке Java и его младшей сестре JavaScript, хотя ее можно встретить также и в других местах. Согласно этому стандарту, все слова в названии начинаются с прописной буквы, кроме первого. При этом, естественно, не используется никаких разделителей вроде нижнего подчеркивания. Обычно данный стандарт применяют к именам функций и переменных, при этом в именах классов (структур, интерфейсов) используется стандарт Pascal. В языке С# camelCase используется частично: область его применения ограничена названиями параметров функций и локальными переменными.

Каждый из этих двух стандартов имеет свои сильные и слабые стороны. Давайте перечислим основные:
  • Нижнее подчеркивание лучше читается: сравните стандарт_с_нижним_подчеркиванием и стандартНаписанияПрописнымиБуквами
  • Зато camel case делает более легким чтение строк, например:
    my_first_var=my_second_var-my_third_var
    и
    myFirstVar=mySecondVar-myThirdVar
    Очевидно, что camel case читается лучше: в случае с нижним подчеркиванием и оператором «минус» выражение с первого взгляда вообще можно принять за одну переменную, однако подсветка синтаксиса может решить эту проблему.
  • Camel Case является противоположностью английского, русского и многих других языков: в обычных языках предложение начинается с большой буквы, а все остальные слова пишутся строчными, в случае с camel case же все происходит наоборот. Это настоящий взрыв мозга
  • Подчеркивание сложнее набирать. Даже при наличии intellisense, во многих случаях необходимо набирать символ нижнего подчеркивания.
  • Camel Case непоследователен, потому что при использовании констант (которые пишутся целиком заглавными буквами) нам приходится использовать нижнее подчеркивание. С другой стороны, стандарт именования с использованием нижнего подчеркивания может быть полным, если вы решите использовать в названиях классов (структур, интерфейсов) нижнее подчеркивание в качестве разделителя




От переводчика: статью старался переводить максимально близко к оригиналу.
От себя добавлю, что в своих проектах предпочитаю использовать Camel Case, только в качестве первого слова использую сокращенный тип переменной (bProductActive, iProductsCount, sUserName), таким образом несколько решается проблема «взрыва мозга» — все слова предложения начинаются с заглавной буквы.

Кроме того, с коллегами очень много споров было на тему аббревиатур при использовании верблюжьей нотации: как писать правильнее GenerateHTMLFromText или GenerateHtmlFromText, в итоге остановились на втором варианте, но чувство нерешенной проблемы все равно немного грызет.

Ну и насчет того, что JavaScript это младшая сестра Java автор немного нагнал, все-таки это совершенно разные языки, общее у них только название и стандарты оформления кода.
Перевод: Sarmad Khalid
Искандер Гиниятуллин @rednaxi
карма
125,0
рейтинг 0,0
WEB-разработчик
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (165)

  • +14
    Достаточно сказать что это вообще нужно использовать, так как начинают почти все с myverysupermegacoolvariable. А уж что выбрать зависит от личных предпочтений и тех библиотек/фреймворков которые используются в разработке.
    • +10
      Это ещё хорошо. Обычно бывает
      bb = j3+a;
      • +1
        мозговая обфускация) видели и такое…
        • +2
          Самое весёлое, что автор кода всё это понимает и знает чуть ли не наизусть…
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              А через месяц после того, как я увидел подобный код, его автор уже там не работал. Я, впрочем, тоже.
    • –2
      а разве это плохо если не более 2-3 слов?

      username
      introtext
      menutitle

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

      under_score в целом менее удобный потому что иногда непонятно, почему в одном случае надо писать first_name, а в другом nickname (путаница с составными словами); кроме того, подчеркивание как разделитель не получается использовать…

      вот пользуясь случае, вопрос:

      как должна называться связь в БД если одна табличка называет user_profiles, а вторая user_relationships, очевидно, что user_profiles_user_relationships, но тут получается путаница, дефисы и заглавные буквы использовать нельзя (заглавные можно, но лучше не использовать)… очень большой соблазн назвать таблички просто userprofiles и userrelationships
      • +2
        user_profiles_2_user_relationships или user_profiles_to_user_relationships :)
        • +1
          Оракл (с его 30 символами на идентификатор) вам руки не подаст!
          • 0
            оракл он такой, да.
            но исходное имя user_profiles_user_relationships уже имеет длину 32 символа :)
  • +12
    То, что вы используете в своих проектах называется венгерской нотацией.
    • –1
      Вы видимо не знаете, что такое Венгерская нотация. Нет, это не то, чему учили вас в школе, что к переменной вначале прибавляется буква, обозначающая тип переменной.

      Чарльз Симонии представил соглашение об именах идентификаторов, в котором для указания функционального назначения объекта, представленного идентификатором используется добавление префикса к имени идентификатора.

      Понимаете? т.е. pX — Указатель на X., а dX Различие между двумя образцами типа X.

      А не то, что принято считать, что sVar — это переменная вида string
      • +1
        Это всего лишь одно из применений нотации. Сама нотация предполагает наличие какого-либо префикса перед именем. В вашем примере префикс отмечает смысловую нагрузку, так же часто используется указание типа. Нотация не ограничивает конкретные префиксы. Соглашение о системе префиксов выбирают сами программисты. Не стоит тыкать в то, что «кто-то впервые предложил». Вещам присуще свойство эволюционировать.
        • +3
          При современном развитии интеллектуальности IDE смысла в префиксе обозначающем тип тем более нет. Поэтому простое отображение типа является деградацией «впервые предложенного».
          • +1
            Разве мои слова как-то противоречат этому?
          • 0
            если речь идет о C++, то IDE сосет.
            если о чистом C, то там вообще из коробки нет продвинутой системы типов, и кроме как нотацией их показать нельзя.
            венгерская нотация применяется, в основном, как раз в C/C++.
            • 0
              NetBeans, Eclipse, VS прекрасно отображают тип переменной при наведении на нее курсора как в C, так и в C++. При чем одинаково хорошо как для встроенных типов, так и для определенных пользователем. В чём оно «сосёт»?
              • 0
                Во встроенных макросах и внешних препроцессорах. Ну да, внутри одного метода оно тип подсветит. А дальше — как бох на душу положит. Но проблема-то глубже. Сегодня VS в каком-то из Qt'шных методов упорно отображала возвращаемый тип как char*, хотя там была ни разу не char* и вообще inline. Поэтому если знаешь какую-то инфу, которую IDE может и не достать, нужно эту инфу тут же укатать в документацию или имена, чтобы с одного взгляда было понятно как и зачем это работает, и не требовалось читать исходник. Лучше пусть метод будет называться calculate_this_fuckin_variable_because_we_must_and_return_int (как в ObjectiveC), чем будет непойми что, работающее непойми как. Имхо.
        • +1
          Там есть отличный пример, описанный в «Возможное Решение #2 », когда венгерской нотацией стараются подпереть как костылём неправильную архитектуру приложения. Необходимо отрефакторить код, view вынести во view и не потребуется больше никаких «us» и «s».
          • 0
            Полностью согласен. Просто в данном разговоре речь шла именно о применении венгерской нотации.
    • +1
      Вернее — неправильным использованием венгерской нотации :).
      У Спольски была статья про это.
      • 0
        Я соглашусь, что прямое указание типа у переменной даже в динамически типизируемых языках затея не самая здравая. Но нельзя же отрицать существование феномена.
        • 0
          Феномен как раз в неправильном употреблении.
          Забивать гвозди микроскопом можно, но называть этот процесс микроскопией всё-таки неправильно :)
      • 0
  • –57
    Терпеть не могу (я бы даже сказал «люто бешено ненавижу и стремлюсь уничтожить») уродства типа этого:

    $functionResult=idioticUglyFunction($stupidVariable),

    а люблю вот это:
    $function_result=beautiful_lovely_function($awesome_variable).

    Как аргумент против коллег — любителей гадкого camelCase привожу документацию пхп: все стандартные функции в нижнем регистре и с подчеркиванием (*гадость из SPL стандартной не считать*).

    PS.
    Не холивара ради. Просто иррационально ненавижу одно и обожаю другое.
    • +25
      Вот только пример с php неудачный. Уж у этих парней в названиях всякого хватает, и с подчеркиваниями, и без, и с логикой, и без неё.
    • +7
      Сохраните нервы — попробуйте не обращать внимания :)
    • +7
      SPL хотя бы имеет какой-то стандарт в отличии от функций, что уже подметили выше. Кроме того, не только то что в рамках SPL имеет camelCase нотацию, напрмиер, большинство ООП вещей в станадртной поставке и модулях. Да и тенденция в PHP явно к camelCase.
    • +2
      При всей моей любви к PHP на названия функций в этом языке не стоило бы ориентироваться. Взять хотя бы функции работы со строками — половина с нижним подчеркиванием, половина — без. Вот хотя бы например stripcslashes и strip_tags — в чем прикол? В одном случае есть подчеркивание, в другом — нет. Как раз таки SPL, как более поздняя разработка, сделана с учетом camelCase как и все прочие разработки Zend (в том числе и Zend Framework), а старые функции с плавающими пробелами — это дань прошлому, естественно сейчас никто ничего менять не будет, ибо надо сохранить совместимость с раними версиями.
      • –1
        Если не ошибаюсь, то имена ф-ций в пхп case-insensitive. И такие ф-ции, как stripcslashes, можно писать как stripCSlashes. Мне что-то подсказывает что так и задумывалось. Это еще больше подтверждает, что смотреть на именование ф-ций безсмысленно, там полная каша.
        • 0
          Там никак не задумывалось :)
          Автор пехапе писал на коленке шаблонизатор для своего сайта, друзья присылали ему новые функции, он их просто добавлял в язык не задумываясь о какой-нибудь стандартизации. Потом язык стал популярным, и корявые имена функций исправлять было поздно.

          Я надеялся, что с переходом на 5.3 или хотя бы на 6.0 функции упорядочат, но увы…
          • 0
            Так а что, уже известно, что в 6-й это все гавно оставят?
            • 0
              Пока ещё даже точно не известно, будет ли 6-я версия :)
              • 0
                Фух, у меня все-таки теплится надежда, что к 6-й версии (а лучше раньше) проведут чистку этого говна. Сам готов поучавствовать в рефакторе.
  • +8
    Реквестирую тонны срача в комментариях к этому посту :)
  • 0
    Я использую camelCase для переменных, а для функций — under_score.
    Например:
    $myVariable = 123;
    
    function print_variable($variableToPrint) {
         echo $variableToPrint; 
    }
    
    • +6
      а я наоборот :)
      для меня Ваш вариант — разрыв шаблона :)
      • 0
        Аналогично :)
      • 0
        Присоединяюсь :)
  • +8
    Я думаю данный холивар актуален только лишь для некоторыз языков. Если вы пишете, скажем на Java или на Руби, врят ли вы будете думать над нотацией — она являвется стандартной для языка.
    • 0
      perldoc.perl.org/perlmodstyle.html — все просто, как написано, так и надо
      • +1
        Damian Conway — Perl Best Practices

        Use underscores to separate words in multiword identifiers.

        TheAlternativeInterCapsApproachIsHarderToReadAndInParticularDoesn'tGeneralizeWellToALLCAPSCONSTANTS
  • +1
    От языка зависит.
  • +13
    Не люблю, когда передёргивают. При использовании подчёркиваний операторы отбиваются пробелами.

    Таким образом:

    • +12
      my_first_var = my_second_var - my_third_var
      и
      myFirstVar=mySecondVar-myThirdVar
      


      Более того, при вызове принято так же отбивать пробелами скобки:

      other_function( first_argument, second_argument );
      • +4
        С первым согласен, а вот со вторым не совсем. Например, Visual Studio сама по умолчанию будет убирать эти пробелы при каждом удобном случае.
        • 0
          Её не сложно отучить это делать…
          • 0
            Да, но зачем?

            Это должна быть заранее оговорённая политика все команды, принимающей участие в разработке. Иначе почти каждый commit будет содержать автоправку от среды.

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

            Каждому новому сотруднику придётся их вдалбливать.
            • 0
              Это если у вас стартап какой-нибудь.
              А если у вас конторе 30 лет и куча написанного кода и стандарты кодирования определенные?
              Мало ли какие настройки для форматирования кода будут в очередной версии очередной среды…
      • +2
        согласен. Хотя недавно встречал интересный пример кода, там пробелы стояли даже перед точкой с запятой, перед скобкой, после скобки, вот в таком стиле:
        a = func ( param, param2 [ 5 ] );
        это был ад… :)
      • +3
        PEP8 не согласен с вами.
      • +1
        Я всегда обрамляю операторы пробелами, и никаких проблем с кодом в любой нотации. Хоть в эмо-стиле оформляй: mYfIrStVaR = mYsEcOnDvAr — mYtHiRdVaR
    • +6
      Во многих стайл гайдах и при использовании camelCase требуется отбивать операторы (а то и всё подряд) пробелами. А вот требований отбивать аргументы при декларировании/вызове как-то не встречалось кажется.
  • +5
    >… в языке Java и его младшей сестре JavaScript…
    Кто-то ввел вас в заблуждение. Кроме 4-х одиаковых букв, между ними ничего общего.
    • 0
      Сорри, не заметил что это перевод.
      • +4
        кроме того что это перевод, я в конце отметил что это разные вещи и автор заблуждается :)
        • +2
          Стоит ли автору верить?
        • 0
          Кстати, почему сестра? оО Какого рода слово «язык» — вроде б не женского?:)
          • 0
            for Java and its little sister JavaScript

            Я думаю потому что Ява — она :)
            • +2
              В английском языке род имеют мужчины, женщины и морские корабли (которые женского рода). Всё остальное — среднего. Ввиду этого они привыкли обращаться с родами вольно.
              В русском — да, «Java» женского рода, но «JavaScript» и «язык»-то — мужского.

              Я бы, в общем, в русском переводе написал что-то вроде «Java и её младший брат JS». Хотя, видимо, это коробит только меня:)
              • 0
                Не только морские. Космические тоже she
              • –1
                Звонят из морга в спортивный магазин:
                — Сколько ваша сеть продала мотоциклов Ява сегодня?
                — Если верить базе, 50.
                — Ясно. Двое еще ездят…
    • 0
      Стиль кода общий (похожий).
  • 0
    Пишу проекты, построенные на технологии ajax, поэтому мне удобно писать всё, что относится к php, на under_score, а всё, что относится к js, на camelCase. Путаницы значительно меньше.
    • +11
      Контактные данные забыл оставить.
      • 0
        «сколько нужно SEOшников, чтобы вкрутить лампочку, лампа, лампы накаливания...» (с)
  • +1
    camelCase не так бьёт по читабельности, как расположение скобок в стиле BSD. Большой гемор потом помочь человеку найти или в чужом коде найти эти скобки: где потерялась.
    • 0
      BSD? Вы уверены, что их так сложно найти? По-моему вы имели ввиду какой-то другой стиль.
      • 0
        имел именно BSD code-styling
        for (var child = parentNode.firstChild; child; child = child.nextSibling) {
          doSomething(child);
        }
    • 0
      Наверное вы все-таки не про BSD, а про K&R или GNU.
      • 0
        Та не, наверное таки про BSD
  • 0
    Кроме того, с коллегами очень много споров было на тему аббревиатур при использовании верблюжьей нотации: как писать правильнее GenerateHTMLFromText или GenerateHtmlFromText, в итоге остановились на втором варианте, но чувство нерешенной проблемы все равно немного грызет.
    Для себя установил правило: если в аббревиатуре больше двух букв — прописной делать только первую букву (XmlRequest), если две буквы — оставлять обе прописные (ADUser).
    • 0
      В частности, в Java есть четкая граница в 3 буквы: XML пишется прописными, но Html пишется уже строчными. Точно такая же граница в 3 буквы установлена и в ActionScript 3. В остальных языках можно писать как угодно.
  • +4
    В Pascal написание имен с использованием разных регистров имеет важное, но лишь декоративное назначение, так как компилятор между регистрами символов различий не делает.
  • +6
    //офтопик
    откуда это вообще пошло «нижнее подчеркивание»? как можно ПОДчеркнуть выше?!!! О_о
    • +3
      • +1
        Вот же мутант он :)
      • 0
        Спасибо за ликбез! Хоть это и не повод оказываться от рудиментов)
      • +3
        Ну и что? Это говорит не о том, что данная фигура речи является правильной, а лишь о том, что ошибка давняя и укоренившаяся.
  • –2
    Ну вообще-то Java и JavaScript братья — у них общий отец. К сожалению, забыл название того языка.
    • +2
      Насколько я знаю, Java был спроектирован с нуля.
      Легче поверить в общего предка человека и обезьяны чем в общий проязык Oak (оригинальное название Java) и LiveScript (оригинальное название JavaScript)

      Первоначально язык JavaScript назывался LiveScript и предназначался как для программирования на стороне клиента, так и для программирования на стороне сервера (там он должен был называться LiveWire). На синтаксис оказали влияние языки Си и Java, и, поскольку Java в то время было модным словом, 4 декабря 1995 года LiveScript переименовали в JavaScript © Википедия.

    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        EcmaScript уже постфактум писали.
  • +2
    Привык уже использовать camelCase — спасибо Zend Framework. Так что насчет популярности подчеркивания среди php-программистов я бы поспорил…
  • +2
    Есть хорошая поговорка: De gustibus non est disputandum
    Но нет-нет — да и появится очередная околохоливарная статься на Хабре…
    • 0
      Для незнающих латынь можно перевод плз? :)

      Все началось с вопроса
      • 0
        о вкусах не спорят
      • 0
        Для незнающих латынь: о вкусах не спорят :)
        • +17
          Quidquid latine dictum sit, altum sonatur.

          Для незнающих латынь: «всё, что сказано на латыни, звучит внушительно».
  • 0
    >как писать правильнее GenerateHTMLFromText или GenerateHtmlFromText, в итоге остановились на втором варианте, но чувство нерешенной проблемы все равно немного грызет.

    Вы выбрали вариант, который рекомендует МС: msdn.microsoft.com/en-us/library/ms229043.aspx
    Для аббревиатур от 3х символов они рекомендуют писать только одну заглавную букву: Html, Olap, Ssrs, но DB, DX, MX и т.д.
    • 0
      Фиг знает. В Java есть классы HtmlURLConnection, но HTMLEditorKit. Есть ZipInputStream, но и GZIPInputStream. Есть как XMLReader, так и XmlReader. Короче, надо писать так, чтобы было понятно — остальное IDE исправит.

      Кстати, по правилам как назвать переменную urlConnection или uRLConnection? )))
      • 0
        Ну вы же знаете правильный ответ:)
  • +1
    символом нижнего подчеркивания (_)
    А какое ещё подчёркивание бывает?
    • 0
      Очевидно, верхнее )) Хотя, кто знает, может и среднее — минус (-) считается..)
    • –2
      Возможно было подчеркивание, одно единственное, а потом появилось «надчеркивание». Но звучало неудобно, поэтому стало два подчеркивания — нижнее и верхнее)))

      ptrue.livejournal.com/414510.html?thread=4433198#t4433198

      У темы другая точка зрения на эту проблему:
      tema.livejournal.com/151813.html?page=2

      В целом термин «нижнее подчеркивание», который обозначает символ _ (против термина «подчеркивание», который обозначает действие) достаточно распространен и я считаю что его вполне можно использовать
      • +2
        Да ладно вам. А «мороженное» тоже по-вашему действие определяет.

        Давайте проведём эксперимент. Я говорю: «в именах используется подчёркивание». И что? Вы в растерянности? Не знаете какое слово я использовал и что оно означает?
  • +1
    Также данный стандарт используется в названиях стандартных функций PHP, и является очень популярным среди PHP-программистов
    Брехня. В PHP нет единого стиля (html_entity_decode, но htmlSpecialChars, прочем часто последнее пишут в одну строку), за что его и ругают.
  • +2
    верблюжья нотация является стандартом в языке Java и его младшей сестре JavaScript
    Java и JavaScript не родственники, а однофамильцы. «JavaScript» — коммерческое название, его придумали маркетологи, тогда как раз Java популярность набирала дикими темпами.
  • +5
    в случае с нижним подчеркиванием и знаком «минус» выражение с первого взгляда вообще можно принять за одну переменную, однако подсветка синтаксиса может решить эту проблему.
    Нормальные люди решают эту проблему форматированием кода. Окружите минус пробелами и вы уже не сможете прочитать ту строку как одну переменную.
  • +2
    Ёпрст, сколько флейма. Используете рекомендации и стандарты, которые определены для вашего языка. Для шарпа, например, целый документ есть, в котором говорится, что и как нужно именовать и какой стиль использовать.
  • +4
    Camel Case является противоположностью английского, русского и многих других языков: в обычных языках предложение начинается с большой буквы, а все остальные слова пишутся строчными
    Дорогой Искандер Гиниятуллин, в России принято писать с большой буквы не только слова в начале предложения.
    • +1
      подозреваю, что автор намекал на немецкий, в котором существительные пишутся с большой буквы (в дополнение к именам, названиям стран, рек, озер и т.д.)
  • +2
    использую в основном under_score, однако в циклах, где нужен счетчик — до сих пор использую i, j, k и им подобное.
    • 0
      однако в циклах, где нужен счетчик — до сих пор использую i, j, k и им подобное
      А что, дают и другие рекомендации?
      • 0
        Не знаю, просто в чужом коде часто вижу в роли счетчиков переменные типа: count_…
  • +1
    Я за camelCase, он на целый байт меньше!
  • +2
    Статья ни о чем.
  • 0
    Хм. А я вот раньше тоже начинал переменную с префикса, указывающего на тип (string sUserName). Тут смысл был скорее (для меня) в том, чтобы набрав первую букву сразу отфильтровать выпадающий список по типу.
    Однако потом как-то прочитал статью, что при нормальном именовании переменных без подобных «пояснений» должно все быть ясно. И на самом деле согласился. Глядя на свой код спустя… я обычно не испытываю проблем с пониманием. Даже вот не знаю. Скажет кто чего?
    • 0
      Найдите статью Джоэля Спольски о венгерской нотации. Варианты вроде sUserName — это профанация, на самом деле.
      Сам не использую, стараюсь именовать так, чтобы было ясно, что там лежит.
      • 0
        Но это Джоэль Спольски так считает.
        Для переменных, типов венгерская нотация может и не подходит,
        но мне удобно ее использовать для объектов интерфейса.

        frmLogin, edtUserName, edtPassword, cmbHostName…

        UserName := frmLogin.edtUserName.Text;

        Вроде читабельно, можно быстро увидеть/разделить интерфейс от логики.

        И это только имхо. И да, это Delphi :) Для других языков, как утверждает Джоэль Спольски, это не всегда подходит.
        • 0
          Я считаю, что Спольски можно доверять. Он аргументированно рассказывает:)

          Ну, для объектов интерфейса — да, может быть. Но я в таких случаях предпочитаю положить все такие объекты в запись (по терминологии Pascal), а потом обращаться как-то так: passwd = form.passwd.value (это JS).
          • 0
            Выше уже приводили ссылки, и если внимательно прочитать, что Джоэль пишет, то можно заметить: Джоэль за Венгерский для приложении и против Системного Венгерского.
            Я же привожу пример, когда даже Системный Венгерский, имхо, вполне не плохо смотрится.
            • 0
              Тип переменной — это не венгерская нотация. Плохо ли это? Да.
              Содержимое переменной — это настоящая венгерская нотация. Хорошо ли это? Может быть.
            • –1
              Вы абсолютно правы используя префиксы.
              Иногда имени переменной не достаточно.
              Одна сущность вполне может быть представлена в нескольких типах.
              Пример:
              string sPhoneNumber = editboxPhoneNumber.Text;
              int nPhoneNumber = int.TryParse(sPhoneNumber);
      • 0
        Точно! Именно у него я вычитал подобное…
  • –1
    Довольно странно, что в переводе (и в оригинале) фигурирует, цитирую:
    Очевидно, что camel case читается лучше: в случае с нижним подчеркиванием и знаком «минус» выражение с первого взгляда [...]

    Знак минус — есть именно знак минус.

    Вы уж простите, но во всех языках используется дефис (черточка). Несмотря на то, что его и называют от природы hyphen-minus (0x2D), в переводе лучше использовать термин «дефис».
    • 0
      В данном случае имелся ввиду оператор минус.
    • 0
      исправил на оператор минус.

      дефис тут все-таки не очень подходит
  • 0
    в Objective-c всегда использовал camelCase
    и сейчас under_score выглядит как вырви глаз 0_о
    хотя когда писал на php вроде пользовался и не жаловался)
    все таки о вкусах не спорят
  • +2
    есть еще BLONDYSTYLE в SQL можно встретить

    и

    ______leading_underscore_style
  • НЛО прилетело и опубликовало эту надпись здесь
  • +3
    Лично я отдаю предпочтение уже существующим стилевым стандартам:
    Исключением является программирование под WinAPI, тут я использую Windows Coding Style Conventions.

    В последнее время искал офоциальный style guide для C#, но так и не нашёл того, что хотел, в той форме, что хотел, поэтому использую свой собственный набор правил.

    Использование подобных стилевых спецификаций создаёт ощущение некой гармонии при написании когда. Просто следуешь наиболее авторитетным стандартам, и не нужно ничего придумывать. А когда создаёшь свой собственный стиль — это немного отвлекает от реализации задачи.
    • +1
      Посмотрите наг гайд по С# комманды RSDN, в принципе он неплох: www.rsdn.ru/article/mag/200401/codestyle.XML
      • 0
        Хороший материал, спасибо. Единственное, что они упустили, — нет примеров if со сложным condition. Например, верно ли так:

        if (false == _processing
            && true == _finished)    // 4 spaces
        {
            // ...
        }
        

        Как тут стоит записывать: по условию на строку, по длине строки (кстати, об этом ничего не сказано) или как-то ещё?
        • +1
          Ну, конкретно тут, я думаю:
          if ( _finished && !_processing )
          {
          //…
          }

          В более сложных случаях я объявляю перед if пару промежуточных переменных, в которых вычисляю части сложного условия, а выражение в if все-равно свожу к двум-трем переменным. У такого подхода целая куча плюсов:
          1. Легче читать код, когда видишь названия этих промежуточных переменных
          2. Легче отлаживать — можно просмотреть значения этих переменных
          3. Короткие выражения в блоке if — более понятно, что происходит.

          Суть этого подхода я вычитал в «Совершенном коде» Макконела.
  • 0
    Венгерская нотация — fffuuu :)

    А так CamelCase самое оно, все методы и классы с заглавной буквы в C#, и методы с маленькой буквы — в JavaScript. Все переменные всегда с маленькой, и для приватных переменных — символ подчеркивания в самом начале.

    Тем не менее названия юнит-тестов называются, скажем так, гибридным образом, например:
    «ActionInvoker_ShouldBe_AbleToBe_Created()»
    или
    " ActionInvoker_Should_Set_The_ActionReturnValue_As_ViewModel_When_It_IsObject_And_Not_An_ActionResult()"
  • +6
    Russian0Perfo0Case
  • +15
    Предлагаю также обсудить, едят ли курицу руками.
    • +3
      Я ем только вилкой и ножиком, чем вызываю бешеное негодование всех родственников. о_0
      • +1
        Хех, заюавно, я обычно тоже, но в итоге вызываю негодование у себя самого, после чего забиваю, и беру руками :)
        • 0
          Ну, у меня почему-то они рассуждают так: «Раз человек не хочет брать курицу руками, значит у него не все в порядке с головой и его надо срочно сдать в дурку на лечение».

          А меня просто бесит брать жирную куру руками — терпеть это не могу. Цивильно и культурно ем вилкой и ножиком. Но их это раздражает.
          • 0
            Ну вот потому, хоть у меня это никого не раздражает, и предпочитаю курицу без костей.
    • +1
      Ну и заодно, что было раньше — яйцо или курица, чего уж там.
    • 0
      Хо-хо, не все так просто. Лично для себя выяснил что курицу удобней всего есть двумя вилками.
  • 0
    Меня лично раздражает именование переменных типа event5 — ничего не понятно из названия.
  • 0
    С другой стороны, верблюжья нотация является стандартом в языке Java и его младшей сестре JavaScript, хотя ее можно встретить также и в других местах. <\i>

    Почему с другой? Параграф выше гласит, что доминирующим стандартом для C/C++ (я бы еще добавил Objective-C) является верблюд и потом пишите что с «другой стороны». По тексту это значит что JAVA должен отличаться, но это не так. Более того в Java очень много взято из C++ и Delphi (источник Bruce Eckel «Thinking in Java»). Так что не удивительно что в нем приняты такие нотации.

    В общем текст ни о чем, а лично мое мнение, что нижнее подчергивание и приватные переменные и функции, который начинаются с нижнего подчеркивания — это все архаизмы, которые каким-то образом до сих пор живы.
    • 0
      Видимо мы видим разные параграфы выше, потому что в том, что вижу я, написано что в С изначально использовался underscore и поэтому при разработке С++ он был принят за стандарт наименования функций в библиотеках STL, Boost.
  • +1
    camelCase — верблюжий чемодан =)))
    • 0
      «Верблюжий случай» тоже звучит ;)
  • 0
    Если бы IDE научились смягчать подчеркивание в именах:



    Хотя, к сожалению, часто приходится иметь дело с уже готовым стилем, где вводить свои порядки как-то неаккуратненько.
    • +1
      Попробуйте использовать VIM/EMACS, там слава богу задать такие стиливые особенности — минутное дело. Кстате, во многих IDE с поддержкой тем тоже это есть, правда не так очевидно и «просто» как в случае с vim/emacs.

      P.S. спасибо за идею =)
  • 0
    лично я юзаю и первый, и второй способ. Утилитки с общим API у меня пишутся на С++, причём общее API используется в виде классов, а само действие утилиты больше написано в процедурном стиле. Соответственно, классовая часть Кэмелом, процедурная — с подчёркиванием. Трудность чтения названия на тамошних размерах пока не пугает, но зато сам себе в голове отделяю вечное (общий API) от бренного (подробности его использования в данном конкретном смысле)
  • 0
    Следующий пост про расстановку скобок? Какие стандарты в проекте определены так и надо писать.
    • 0
      Про скобки уже было: habrahabr.ru/blogs/php/37831/ :)
      • +2
        Старый какой пост. Пора оживить тему, голосование устроить :)
  • 0
    Я бы ещё добавил, что андерскоры удлиняют длину строки. Что усложняет ситуацию, если на эту самую длину в соглашениях установлен лимит.
  • 0
    А я не парюсь, в большинстве случаев нотацию диктует используемый фреймворк. И лучше ей следовать, не то зоопарк гарантирован.
  • 0
    Юзаю везде under_score, так повелось еще с институтского с++, но когда изучал Livestreet оценил венгерскую нотацию с кэмел кейзом — очень удобно разбираться в чужом коде с ней.
  • 0
    Мде… Разве не логично писать так, как диктуют стайлгайды к конкретному языку?..
  • 0
    в camelCase раздражает, когда в имени переменной есть предлог или аббревиатура. как в таком случае поступать? например как написать «RGB to color» или «is GPS connected» и в таком духе?
    • +1
      Предположу что можно использовать модули.

      RGB::to_color()
      GPS::is_connected?()

      на самом деле очень удобно, правда такая ситуация в руби, как с другими языками — не знаю.
    • 0
      rgbToColor
      isGpsConnected
  • 0
    В руби:

    обычные переменные: my_super_var
    контанты и имена классов/модулей: MySuperClass, MySuperConst
    • 0
      Неправда, константы в руби пишутся так: MY_SUPER_CONST
      Что интересно, переменные обязательно должны начинаться с маленькой, а константы/классы — с большой буквы, иначе ошибка.
      • 0
        ой, точно, перепутал =)
  • –1
    Добавлю и от себя пять копеек. Одно из «преимуществ» camelCase — более короткие идентификаторы. Так как мы по возможности стараемся укладывать код в 80 символов (не потому что монитор маленький, а потому что diff, 3-way merge и консоль), то сокращение длины идентификаторов играет немаловажную роль, увы. Плюс camelCase позволяет в сильно меньшее количество символов приклеивать к идентификаторам тип. Венгерская нотация, конечно, зло, но для ряда случаев все же используется:

    nItemId = 42 # идетификатор с "n" короче.
    s_item_id = "{42-000-000}" # идентификатор в "s" длиннее за счет подчеркиваний.
    
    nItemId = oActiveUsers.Find( sUserName, eUserGender, sUserCompany )
    # Чем больше составных идентификаторов в satement - тем строки длиннее.
    # Конечно, 5-10 % длины строки это не так уж много - но в ряде случаев не так уж и мало :). 
    n_item_id = o_active_users.find( s_name, e_user_gender, s_user_company )
    

  • 0
    А помоему пофиг как выглядит кодинг-стандарт — главное что б он был и его придерживались все участники проекта.
  • –2
    >только в качестве первого слова использую сокращенный тип переменной (bProductActive, iProductsCount, sUserName)

    Я использую префиксы 'm' для полей класса и 'k' для констант.
  • 0
    в Ruby например от первой буквы зависит будет ли у вас это константа (класс) или переменная, CONST = 6 или const = 6; const =+ 1; можно
    Классы так же по соглашению именуются NewsController, но методы и переменные under score hello_kitty

    Этого же я придерживаюсь в PHP (CodeIgniter framework) и всегда против Camel Case так как в речи у нас всегда между словами есть пробелы (ну может кроме в тайской речи)
  • 0
    Использование camelCase в Eclipse дает несравненое преимущество по сравнению с under_score в плане автодополнения. Например, если у вас есть класс MyAwesomeMegaClass, то достаточно будет набрать в эдиторе MAMC, нажать ctrl+space и IDE автоматически найдет все совпадения названий по camelCase и скорее всего единственным совпадением будет имя вашего класса. То же самое работает для переменных и методов, что очень сильно ускоряет кодописание.
    • 0
      ну да, он ищет по большим буквам, что мешает искать не по

      M A M C

      а по

      m _a _m _c

      ?
      • 0
        как минимум то, что это не поддерживается эклипсом?
        по крайней мере голый эклипс с подчеркиваниями не работает.
  • 0
    Глупо раздувать холивар из ничего. У каждого приличного языка есть правила именования.

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