rednaxi 2 фев 2011 в 15:58

camelCase против under_score

3 мин

80K

Качество кода *

Перевод

165

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

fozzy 2 фев 2011 в 16:05

Достаточно сказать что это вообще нужно использовать, так как начинают почти все с myverysupermegacoolvariable. А уж что выбрать зависит от личных предпочтений и тех библиотек/фреймворков которые используются в разработке.

adontz 2 фев 2011 в 16:37

Это ещё хорошо. Обычно бывает
bb = j3+a;

fozzy 2 фев 2011 в 16:39

мозговая обфускация) видели и такое…

r00tkit 2 фев 2011 в 20:28

Самое весёлое, что автор кода всё это понимает и знает чуть ли не наизусть…

НЛО прилетело и опубликовало эту надпись здесь

torbasow 5 фев 2011 в 13:22

А через месяц после того, как я увидел подобный код, его автор уже там не работал. Я, впрочем, тоже.

Lord_Daedra 3 фев 2011 в 10:40

а разве это плохо если не более 2-3 слов?

username
introtext
menutitle

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

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

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

как должна называться связь в БД если одна табличка называет user_profiles, а вторая user_relationships, очевидно, что user_profiles_user_relationships, но тут получается путаница, дефисы и заглавные буквы использовать нельзя (заглавные можно, но лучше не использовать)… очень большой соблазн назвать таблички просто userprofiles и userrelationships

fifonik 3 фев 2011 в 10:56

user_profiles_2_user_relationships или user_profiles_to_user_relationships :)

alienator 3 фев 2011 в 18:32

Оракл (с его 30 символами на идентификатор) вам руки не подаст!

fifonik 3 фев 2011 в 21:38

оракл он такой, да.
но исходное имя user_profiles_user_relationships уже имеет длину 32 символа :)

Leeb 2 фев 2011 в 16:13

То, что вы используете в своих проектах называется венгерской нотацией.

Shersh 3 фев 2011 в 08:58

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

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

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

А не то, что принято считать, что sVar — это переменная вида string

Leeb 3 фев 2011 в 09:12

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

mrFox 3 фев 2011 в 09:15

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

Leeb 3 фев 2011 в 09:23

Разве мои слова как-то противоречат этому?

olegchir 17 июн 2013 в 02:27

если речь идет о C++, то IDE сосет.
если о чистом C, то там вообще из коробки нет продвинутой системы типов, и кроме как нотацией их показать нельзя.
венгерская нотация применяется, в основном, как раз в C/C++.

mrFox 17 июн 2013 в 06:09

NetBeans, Eclipse, VS прекрасно отображают тип переменной при наведении на нее курсора как в C, так и в C++. При чем одинаково хорошо как для встроенных типов, так и для определенных пользователем. В чём оно «сосёт»?

olegchir 17 июн 2013 в 07:54

Во встроенных макросах и внешних препроцессорах. Ну да, внутри одного метода оно тип подсветит. А дальше — как бох на душу положит. Но проблема-то глубже. Сегодня VS в каком-то из Qt'шных методов упорно отображала возвращаемый тип как char*, хотя там была ни разу не char* и вообще inline. Поэтому если знаешь какую-то инфу, которую IDE может и не достать, нужно эту инфу тут же укатать в документацию или имена, чтобы с одного взгляда было понятно как и зачем это работает, и не требовалось читать исходник. Лучше пусть метод будет называться calculate_this_fuckin_variable_because_we_must_and_return_int (как в ObjectiveC), чем будет непойми что, работающее непойми как. Имхо.

mrFox 3 фев 2011 в 09:13

local.joelonsoftware.com/wiki/Как_заставить_неправильный_код_выглядеть_неправильно

TheShock 3 фев 2011 в 19:30

Там есть отличный пример, описанный в «Возможное Решение #2 », когда венгерской нотацией стараются подпереть как костылём неправильную архитектуру приложения. Необходимо отрефакторить код, view вынести во view и не потребуется больше никаких «us» и «s».

mrFox 4 фев 2011 в 06:47

Полностью согласен. Просто в данном разговоре речь шла именно о применении венгерской нотации.

dime 3 фев 2011 в 09:10

Вернее — неправильным использованием венгерской нотации :).
У Спольски была статья про это.

Leeb 3 фев 2011 в 09:13

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

dime 3 фев 2011 в 12:08

Феномен как раз в неправильном употреблении.
Забивать гвозди микроскопом можно, но называть этот процесс микроскопией всё-таки неправильно :)

Shersh 3 фев 2011 в 09:15

Да, именно это и я имел ввиду выше.
local.joelonsoftware.com/mediawiki/index.php/Как_заставить_неправильный_код_выглядеть_неправильно

moooV 2 фев 2011 в 16:20

Терпеть не могу (я бы даже сказал «люто бешено ненавижу и стремлюсь уничтожить») уродства типа этого:

$functionResult=idioticUglyFunction($stupidVariable),

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

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

PS.
Не холивара ради. Просто иррационально ненавижу одно и обожаю другое.

khizhaster 2 фев 2011 в 16:24

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

Okspen 2 фев 2011 в 16:26

Сохраните нервы — попробуйте не обращать внимания :)

chEbba 2 фев 2011 в 17:42

SPL хотя бы имеет какой-то стандарт в отличии от функций, что уже подметили выше. Кроме того, не только то что в рамках SPL имеет camelCase нотацию, напрмиер, большинство ООП вещей в станадртной поставке и модулях. Да и тенденция в PHP явно к camelCase.

StraNNikk 3 фев 2011 в 09:00

При всей моей любви к PHP на названия функций в этом языке не стоило бы ориентироваться. Взять хотя бы функции работы со строками — половина с нижним подчеркиванием, половина — без. Вот хотя бы например stripcslashes и strip_tags — в чем прикол? В одном случае есть подчеркивание, в другом — нет. Как раз таки SPL, как более поздняя разработка, сделана с учетом camelCase как и все прочие разработки Zend (в том числе и Zend Framework), а старые функции с плавающими пробелами — это дань прошлому, естественно сейчас никто ничего менять не будет, ибо надо сохранить совместимость с раними версиями.

kastigar 3 фев 2011 в 10:38

Если не ошибаюсь, то имена ф-ций в пхп case-insensitive. И такие ф-ции, как stripcslashes, можно писать как stripCSlashes. Мне что-то подсказывает что так и задумывалось. Это еще больше подтверждает, что смотреть на именование ф-ций безсмысленно, там полная каша.

Goodkat 3 фев 2011 в 19:01

Там никак не задумывалось :)
Автор пехапе писал на коленке шаблонизатор для своего сайта, друзья присылали ему новые функции, он их просто добавлял в язык не задумываясь о какой-нибудь стандартизации. Потом язык стал популярным, и корявые имена функций исправлять было поздно.

Я надеялся, что с переходом на 5.3 или хотя бы на 6.0 функции упорядочат, но увы…

kastigar 3 фев 2011 в 19:17

Так а что, уже известно, что в 6-й это все гавно оставят?

Goodkat 4 фев 2011 в 11:51

Пока ещё даже точно не известно, будет ли 6-я версия :)

kastigar 4 фев 2011 в 11:59

Фух, у меня все-таки теплится надежда, что к 6-й версии (а лучше раньше) проведут чистку этого говна. Сам готов поучавствовать в рефакторе.

braindamaged 2 фев 2011 в 16:24

Реквестирую тонны срача в комментариях к этому посту :)

agul 2 фев 2011 в 16:27

Я использую camelCase для переменных, а для функций — under_score.
Например:

$myVariable = 123;

function print_variable($variableToPrint) {
     echo $variableToPrint; 
}

LionAlex 3 фев 2011 в 07:51

а я наоборот :)
для меня Ваш вариант — разрыв шаблона :)

ndubinkin 3 фев 2011 в 08:34

Аналогично :)

shoumikhin 3 фев 2011 в 12:41

Присоединяюсь :)

НЛО прилетело и опубликовало эту надпись здесь

holivar 3 фев 2011 в 08:26

perldoc.perl.org/perlmodstyle.html — все просто, как написано, так и надо

ludenus 3 фев 2011 в 10:22

Damian Conway — Perl Best Practices

Use underscores to separate words in multiword identifiers.
…
TheAlternativeInterCapsApproachIsHarderToReadAndInParticularDoesn'tGeneralizeWellToALLCAPSCONSTANTS

JayDi 2 фев 2011 в 16:38

От языка зависит.

amarao 2 фев 2011 в 16:38

Не люблю, когда передёргивают. При использовании подчёркиваний операторы отбиваются пробелами.

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

amarao 2 фев 2011 в 16:40

my_first_var = my_second_var - my_third_var
и
myFirstVar=mySecondVar-myThirdVar

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

other_function( first_argument, second_argument );

Barman 3 фев 2011 в 07:50

С первым согласен, а вот со вторым не совсем. Например, Visual Studio сама по умолчанию будет убирать эти пробелы при каждом удобном случае.

Vile55 3 фев 2011 в 11:34

Её не сложно отучить это делать…

Barman 3 фев 2011 в 12:44

Да, но зачем?

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

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

Каждому новому сотруднику придётся их вдалбливать.

Vile55 3 фев 2011 в 12:50

Это если у вас стартап какой-нибудь.
А если у вас конторе 30 лет и куча написанного кода и стандарты кодирования определенные?
Мало ли какие настройки для форматирования кода будут в очередной версии очередной среды…

AmirL 3 фев 2011 в 08:04

согласен. Хотя недавно встречал интересный пример кода, там пробелы стояли даже перед точкой с запятой, перед скобкой, после скобки, вот в таком стиле:
a = func ( param, param2 [ 5 ] );
это был ад… :)

karellen 3 фев 2011 в 08:07

PEP8 не согласен с вами.

burjui 3 фев 2011 в 12:08

Я всегда обрамляю операторы пробелами, и никаких проблем с кодом в любой нотации. Хоть в эмо-стиле оформляй: mYfIrStVaR = mYsEcOnDvAr — mYtHiRdVaR

VolCh 3 фев 2011 в 07:03

Во многих стайл гайдах и при использовании camelCase требуется отбивать операторы (а то и всё подряд) пробелами. А вот требований отбивать аргументы при декларировании/вызове как-то не встречалось кажется.

unkind 2 фев 2011 в 17:01

>… в языке Java и его младшей сестре JavaScript…
Кто-то ввел вас в заблуждение. Кроме 4-х одиаковых букв, между ними ничего общего.

unkind 2 фев 2011 в 17:04

Сорри, не заметил что это перевод.

rednaxi 2 фев 2011 в 17:33

кроме того что это перевод, я в конце отметил что это разные вещи и автор заблуждается :)

tnz 2 фев 2011 в 23:34

Стоит ли автору верить?

k12th 3 фев 2011 в 08:18

Кстати, почему сестра? оО Какого рода слово «язык» — вроде б не женского?:)

rednaxi 3 фев 2011 в 08:19

for Java and its little sister JavaScript

Я думаю потому что Ява — она :)

k12th 3 фев 2011 в 08:26

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

Я бы, в общем, в русском переводе написал что-то вроде «Java и её младший брат JS». Хотя, видимо, это коробит только меня:)

valerypride 3 фев 2011 в 08:56

Не только морские. Космические тоже she

mordet 3 фев 2011 в 09:02

Звонят из морга в спортивный магазин:
— Сколько ваша сеть продала мотоциклов Ява сегодня?
— Если верить базе, 50.
— Ясно. Двое еще ездят…

Dair_Targ 3 фев 2011 в 08:25

Стиль кода общий (похожий).

VitaZheltyakov 2 фев 2011 в 17:17

Пишу проекты, построенные на технологии ajax, поэтому мне удобно писать всё, что относится к php, на under_score, а всё, что относится к js, на camelCase. Путаницы значительно меньше.

leorik 3 фев 2011 в 08:05

Контактные данные забыл оставить.

LionAlex 3 фев 2011 в 12:48

«сколько нужно SEOшников, чтобы вкрутить лампочку, лампа, лампы накаливания...» (с)

romy4 2 фев 2011 в 17:23

camelCase не так бьёт по читабельности, как расположение скобок в стиле BSD. Большой гемор потом помочь человеку найти или в чужом коде найти эти скобки: где потерялась.

Smi1e 2 фев 2011 в 23:11

BSD? Вы уверены, что их так сложно найти? По-моему вы имели ввиду какой-то другой стиль.

romy4 11 фев 2011 в 22:15

имел именно BSD code-styling

for (var child = parentNode.firstChild; child; child = child.nextSibling) {
  doSomething(child);
}

gouranga 3 фев 2011 в 10:43

Наверное вы все-таки не про BSD, а про K&R или GNU.

TheShock 3 фев 2011 в 19:42

Та не, наверное таки про BSD

khaale 2 фев 2011 в 17:25

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

Для себя установил правило: если в аббревиатуре больше двух букв — прописной делать только первую букву (XmlRequest), если две буквы — оставлять обе прописные (ADUser).

paladin 3 фев 2011 в 09:00

В частности, в Java есть четкая граница в 3 буквы: XML пишется прописными, но Html пишется уже строчными. Точно такая же граница в 3 буквы установлена и в ActionScript 3. В остальных языках можно писать как угодно.

JerryJJ 2 фев 2011 в 17:47

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

imeninnik 2 фев 2011 в 21:59

//офтопик
откуда это вообще пошло «нижнее подчеркивание»? как можно ПОДчеркнуть выше?!!! О_о

rednaxi 2 фев 2011 в 22:37

tema.livejournal.com/151813.html?page=2

НЛО прилетело и опубликовало эту надпись здесь

imeninnik 3 фев 2011 в 08:06

Спасибо за ликбез! Хоть это и не повод оказываться от рудиментов)

alcanoid 3 фев 2011 в 10:03

Ну и что? Это говорит не о том, что данная фигура речи является правильной, а лишь о том, что ошибка давняя и укоренившаяся.

НЛО прилетело и опубликовало эту надпись здесь

general 2 фев 2011 в 22:31

Насколько я знаю, Java был спроектирован с нуля.
Легче поверить в общего предка человека и обезьяны чем в общий проязык Oak (оригинальное название Java) и LiveScript (оригинальное название JavaScript)

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

НЛО прилетело и опубликовало эту надпись здесь

sl4mmer 3 фев 2011 в 07:30

Привык уже использовать camelCase — спасибо Zend Framework. Так что насчет популярности подчеркивания среди php-программистов я бы поспорил…

lexor 3 фев 2011 в 07:41

Есть хорошая поговорка: De gustibus non est disputandum
Но нет-нет — да и появится очередная околохоливарная статься на Хабре…

rednaxi 3 фев 2011 в 07:45

Для незнающих латынь можно перевод плз? :)

Все началось с вопроса

ivann 3 фев 2011 в 07:46

о вкусах не спорят

ivann 3 фев 2011 в 07:47

Есть хороший топик на вики: en.wikipedia.org/wiki/List_of_Latin_phrases

lexor 3 фев 2011 в 07:47

Для незнающих латынь: о вкусах не спорят :)

bolk 3 фев 2011 в 07:55

Quidquid latine dictum sit, altum sonatur.

Для незнающих латынь: «всё, что сказано на латыни, звучит внушительно».

ivann 3 фев 2011 в 07:46

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

Вы выбрали вариант, который рекомендует МС: msdn.microsoft.com/en-us/library/ms229043.aspx
Для аббревиатур от 3х символов они рекомендуют писать только одну заглавную букву: Html, Olap, Ssrs, но DB, DX, MX и т.д.

Throwable 3 фев 2011 в 11:23

Фиг знает. В Java есть классы HtmlURLConnection, но HTMLEditorKit. Есть ZipInputStream, но и GZIPInputStream. Есть как XMLReader, так и XmlReader. Короче, надо писать так, чтобы было понятно — остальное IDE исправит.

Кстати, по правилам как назвать переменную urlConnection или uRLConnection? )))

ivann 3 фев 2011 в 11:27

Ну вы же знаете правильный ответ:)

bolk 3 фев 2011 в 07:46

символом нижнего подчеркивания (_)

А какое ещё подчёркивание бывает?

НЛО прилетело и опубликовало эту надпись здесь

rednaxi 3 фев 2011 в 08:03

Возможно было подчеркивание, одно единственное, а потом появилось «надчеркивание». Но звучало неудобно, поэтому стало два подчеркивания — нижнее и верхнее)))

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

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

В целом термин «нижнее подчеркивание», который обозначает символ _ (против термина «подчеркивание», который обозначает действие) достаточно распространен и я считаю что его вполне можно использовать

bolk 3 фев 2011 в 12:13

Да ладно вам. А «мороженное» тоже по-вашему действие определяет.

Давайте проведём эксперимент. Я говорю: «в именах используется подчёркивание». И что? Вы в растерянности? Не знаете какое слово я использовал и что оно означает?

bolk 3 фев 2011 в 07:48

Также данный стандарт используется в названиях стандартных функций PHP, и является очень популярным среди PHP-программистов

Брехня. В PHP нет единого стиля (html_entity_decode, но htmlSpecialChars, прочем часто последнее пишут в одну строку), за что его и ругают.

bolk 3 фев 2011 в 07:49

верблюжья нотация является стандартом в языке Java и его младшей сестре JavaScript

Java и JavaScript не родственники, а однофамильцы. «JavaScript» — коммерческое название, его придумали маркетологи, тогда как раз Java популярность набирала дикими темпами.

bolk 3 фев 2011 в 07:51

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

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

Cryptochild 3 фев 2011 в 07:52

Ёпрст, сколько флейма. Используете рекомендации и стандарты, которые определены для вашего языка. Для шарпа, например, целый документ есть, в котором говорится, что и как нужно именовать и какой стиль использовать.

bolk 3 фев 2011 в 07:52

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

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

klz 3 фев 2011 в 10:53

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

slaventium 3 фев 2011 в 07:57

использую в основном under_score, однако в циклах, где нужен счетчик — до сих пор использую i, j, k и им подобное.

ruzzz 3 фев 2011 в 08:53

однако в циклах, где нужен счетчик — до сих пор использую i, j, k и им подобное

А что, дают и другие рекомендации?

slaventium 3 фев 2011 в 09:12

Не знаю, просто в чужом коде часто вижу в роли счетчиков переменные типа: count_…

VadNov 3 фев 2011 в 08:00

Я за camelCase, он на целый байт меньше!

hellman 3 фев 2011 в 08:01

Статья ни о чем.

kpower 3 фев 2011 в 08:04

Хм. А я вот раньше тоже начинал переменную с префикса, указывающего на тип (string sUserName). Тут смысл был скорее (для меня) в том, чтобы набрав первую букву сразу отфильтровать выпадающий список по типу.
Однако потом как-то прочитал статью, что при нормальном именовании переменных без подобных «пояснений» должно все быть ясно. И на самом деле согласился. Глядя на свой код спустя… я обычно не испытываю проблем с пониманием. Даже вот не знаю. Скажет кто чего?

k12th 3 фев 2011 в 08:30

Найдите статью Джоэля Спольски о венгерской нотации. Варианты вроде sUserName — это профанация, на самом деле.
Сам не использую, стараюсь именовать так, чтобы было ясно, что там лежит.

toxicdream 3 фев 2011 в 09:09

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

frmLogin, edtUserName, edtPassword, cmbHostName…

UserName := frmLogin.edtUserName.Text;

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

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

k12th 3 фев 2011 в 09:20

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

Ну, для объектов интерфейса — да, может быть. Но я в таких случаях предпочитаю положить все такие объекты в запись (по терминологии Pascal), а потом обращаться как-то так: passwd = form.passwd.value (это JS).

toxicdream 3 фев 2011 в 09:59

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

k12th 3 фев 2011 в 10:02

Тип переменной — это не венгерская нотация. Плохо ли это? Да.
Содержимое переменной — это настоящая венгерская нотация. Хорошо ли это? Может быть.

general 3 фев 2011 в 10:28

Вы абсолютно правы используя префиксы.
Иногда имени переменной не достаточно.
Одна сущность вполне может быть представлена в нескольких типах.
Пример:
string sPhoneNumber = editboxPhoneNumber.Text;
int nPhoneNumber = int.TryParse(sPhoneNumber);

kpower 5 фев 2011 в 09:52

Точно! Именно у него я вычитал подобное…

myadzel 3 фев 2011 в 08:06

Довольно странно, что в переводе (и в оригинале) фигурирует, цитирую:

Очевидно, что camel case читается лучше: в случае с нижним подчеркиванием и знаком «минус» выражение с первого взгляда [...]

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

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

НЛО прилетело и опубликовало эту надпись здесь

rednaxi 3 фев 2011 в 08:12

исправил на оператор минус.

дефис тут все-таки не очень подходит

IeN 3 фев 2011 в 08:14

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

ncix 3 фев 2011 в 08:15

есть еще BLONDYSTYLE в SQL можно встретить

и

______leading_underscore_style

НЛО прилетело и опубликовало эту надпись здесь

Akenfold 3 фев 2011 в 08:17

Лично я отдаю предпочтение уже существующим стилевым стандартам:

Исключением является программирование под WinAPI, тут я использую Windows Coding Style Conventions.

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

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

tangro 3 фев 2011 в 08:30

Посмотрите наг гайд по С# комманды RSDN, в принципе он неплох: www.rsdn.ru/article/mag/200401/codestyle.XML

Akenfold 3 фев 2011 в 08:52

Хороший материал, спасибо. Единственное, что они упустили, — нет примеров if со сложным condition. Например, верно ли так:

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

Как тут стоит записывать: по условию на строку, по длине строки (кстати, об этом ничего не сказано) или как-то ещё?

tangro 3 фев 2011 в 10:10

Ну, конкретно тут, я думаю:
if ( _finished && !_processing )
{
//…
}

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

Суть этого подхода я вычитал в «Совершенном коде» Макконела.

VasilioRuzanni 3 фев 2011 в 08:19

Венгерская нотация — fffuuu :)

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

Тем не менее названия юнит-тестов называются, скажем так, гибридным образом, например:
«ActionInvoker_ShouldBe_AbleToBe_Created()»
или
" ActionInvoker_Should_Set_The_ActionReturnValue_As_ViewModel_When_It_IsObject_And_Not_An_ActionResult()"

holivar 3 фев 2011 в 08:28

Russian0Perfo0Case

ilukyanov 3 фев 2011 в 08:37

Предлагаю также обсудить, едят ли курицу руками.

moooV 3 фев 2011 в 10:08

Я ем только вилкой и ножиком, чем вызываю бешеное негодование всех родственников. о_0

VasilioRuzanni 3 фев 2011 в 11:12

Хех, заюавно, я обычно тоже, но в итоге вызываю негодование у себя самого, после чего забиваю, и беру руками :)

moooV 3 фев 2011 в 11:22

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

А меня просто бесит брать жирную куру руками — терпеть это не могу. Цивильно и культурно ем вилкой и ножиком. Но их это раздражает.

VasilioRuzanni 3 фев 2011 в 11:29

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

tangro 3 фев 2011 в 10:11

Ну и заодно, что было раньше — яйцо или курица, чего уж там.

AlexanderYastrebov 3 фев 2011 в 12:40

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

kicum 3 фев 2011 в 08:37

Меня лично раздражает именование переменных типа event5 — ничего не понятно из названия.

rule 3 фев 2011 в 08:43

С другой стороны, верблюжья нотация является стандартом в языке Java и его младшей сестре JavaScript, хотя ее можно встретить также и в других местах. <\i>

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

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

rednaxi 3 фев 2011 в 08:58

Видимо мы видим разные параграфы выше, потому что в том, что вижу я, написано что в С изначально использовался underscore и поэтому при разработке С++ он был принят за стандарт наименования функций в библиотеках STL, Boost.

TEHEK 3 фев 2011 в 08:45

camelCase — верблюжий чемодан =)))

Akenfold 3 фев 2011 в 08:53

«Верблюжий случай» тоже звучит ;)

sphere 3 фев 2011 в 08:56

Если бы IDE научились смягчать подчеркивание в именах:

Хотя, к сожалению, часто приходится иметь дело с уже готовым стилем, где вводить свои порядки как-то неаккуратненько.

narciruss 3 фев 2011 в 09:31

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

P.S. спасибо за идею =)

bitterman 3 фев 2011 в 08:57

лично я юзаю и первый, и второй способ. Утилитки с общим API у меня пишутся на С++, причём общее API используется в виде классов, а само действие утилиты больше написано в процедурном стиле. Соответственно, классовая часть Кэмелом, процедурная — с подчёркиванием. Трудность чтения названия на тамошних размерах пока не пугает, но зато сам себе в голове отделяю вечное (общий API) от бренного (подробности его использования в данном конкретном смысле)

valerypride 3 фев 2011 в 08:59

Следующий пост про расстановку скобок? Какие стандарты в проекте определены так и надо писать.

rednaxi 3 фев 2011 в 09:06

Про скобки уже было: habrahabr.ru/blogs/php/37831/ :)

valerypride 3 фев 2011 в 09:10

Старый какой пост. Пора оживить тему, голосование устроить :)

DmitriKadykov 3 фев 2011 в 08:59

Я бы ещё добавил, что андерскоры удлиняют длину строки. Что усложняет ситуацию, если на эту самую длину в соглашениях установлен лимит.

MastaEx 3 фев 2011 в 09:00

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

ajaxtelamonid 3 фев 2011 в 09:10

Юзаю везде under_score, так повелось еще с институтского с++, но когда изучал Livestreet оценил венгерскую нотацию с кэмел кейзом — очень удобно разбираться в чужом коде с ней.

alprk 3 фев 2011 в 09:12

Мде… Разве не логично писать так, как диктуют стайлгайды к конкретному языку?..

iPavel 3 фев 2011 в 09:21

в camelCase раздражает, когда в имени переменной есть предлог или аббревиатура. как в таком случае поступать? например как написать «RGB to color» или «is GPS connected» и в таком духе?

narciruss 3 фев 2011 в 09:28

Предположу что можно использовать модули.

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

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

TheShock 3 фев 2011 в 20:03

rgbToColor isGpsConnected

narciruss 3 фев 2011 в 09:26

В руби:

обычные переменные: my_super_var
контанты и имена классов/модулей: MySuperClass, MySuperConst

HhyperR 3 фев 2011 в 13:01

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

narciruss 3 фев 2011 в 13:05

ой, точно, перепутал =)

grigoryvp 3 фев 2011 в 09:27

Добавлю и от себя пять копеек. Одно из «преимуществ» 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 )

rozembom 3 фев 2011 в 09:58

А помоему пофиг как выглядит кодинг-стандарт — главное что б он был и его придерживались все участники проекта.

Levsha100 3 фев 2011 в 10:28

>только в качестве первого слова использую сокращенный тип переменной (bProductActive, iProductsCount, sUserName)

Я использую префиксы 'm' для полей класса и 'k' для констант.

MpaK999 3 фев 2011 в 10:58

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

Этого же я придерживаюсь в PHP (CodeIgniter framework) и всегда против Camel Case так как в речи у нас всегда между словами есть пробелы (ну может кроме в тайской речи)

nocach 3 фев 2011 в 11:57

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

narciruss 3 фев 2011 в 13:06

ну да, он ищет по большим буквам, что мешает искать не по

M A M C

а по

m _a _m _c

?

nocach 3 фев 2011 в 13:13

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

boh 3 фев 2011 в 15:05

Глупо раздувать холивар из ничего. У каждого приличного языка есть правила именования.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий