Комментарии 165
Достаточно сказать что это вообще нужно использовать, так как начинают почти все с myverysupermegacoolvariable. А уж что выбрать зависит от личных предпочтений и тех библиотек/фреймворков которые используются в разработке.
Это ещё хорошо. Обычно бывает
bb = j3+a;
bb = j3+a;
а разве это плохо если не более 2-3 слов?
username
introtext
menutitle
camelCase симпатичный, но иногда не хочет нажимать на шифт) а иногда не хочется использовать заглавные буквы (базы данных)
under_score в целом менее удобный потому что иногда непонятно, почему в одном случае надо писать first_name, а в другом nickname (путаница с составными словами); кроме того, подчеркивание как разделитель не получается использовать…
вот пользуясь случае, вопрос:
как должна называться связь в БД если одна табличка называет user_profiles, а вторая user_relationships, очевидно, что user_profiles_user_relationships, но тут получается путаница, дефисы и заглавные буквы использовать нельзя (заглавные можно, но лучше не использовать)… очень большой соблазн назвать таблички просто userprofiles и userrelationships
username
introtext
menutitle
camelCase симпатичный, но иногда не хочет нажимать на шифт) а иногда не хочется использовать заглавные буквы (базы данных)
under_score в целом менее удобный потому что иногда непонятно, почему в одном случае надо писать first_name, а в другом nickname (путаница с составными словами); кроме того, подчеркивание как разделитель не получается использовать…
вот пользуясь случае, вопрос:
как должна называться связь в БД если одна табличка называет user_profiles, а вторая user_relationships, очевидно, что user_profiles_user_relationships, но тут получается путаница, дефисы и заглавные буквы использовать нельзя (заглавные можно, но лучше не использовать)… очень большой соблазн назвать таблички просто userprofiles и userrelationships
То, что вы используете в своих проектах называется венгерской нотацией.
Вы видимо не знаете, что такое Венгерская нотация. Нет, это не то, чему учили вас в школе, что к переменной вначале прибавляется буква, обозначающая тип переменной.
Чарльз Симонии представил соглашение об именах идентификаторов, в котором для указания функционального назначения объекта, представленного идентификатором используется добавление префикса к имени идентификатора.
Понимаете? т.е. pX — Указатель на X., а dX Различие между двумя образцами типа X.
А не то, что принято считать, что sVar — это переменная вида string
Чарльз Симонии представил соглашение об именах идентификаторов, в котором для указания функционального назначения объекта, представленного идентификатором используется добавление префикса к имени идентификатора.
Понимаете? т.е. pX — Указатель на X., а dX Различие между двумя образцами типа X.
А не то, что принято считать, что sVar — это переменная вида string
Это всего лишь одно из применений нотации. Сама нотация предполагает наличие какого-либо префикса перед именем. В вашем примере префикс отмечает смысловую нагрузку, так же часто используется указание типа. Нотация не ограничивает конкретные префиксы. Соглашение о системе префиксов выбирают сами программисты. Не стоит тыкать в то, что «кто-то впервые предложил». Вещам присуще свойство эволюционировать.
При современном развитии интеллектуальности IDE смысла в префиксе обозначающем тип тем более нет. Поэтому простое отображение типа является деградацией «впервые предложенного».
Разве мои слова как-то противоречат этому?
если речь идет о C++, то IDE сосет.
если о чистом C, то там вообще из коробки нет продвинутой системы типов, и кроме как нотацией их показать нельзя.
венгерская нотация применяется, в основном, как раз в C/C++.
если о чистом C, то там вообще из коробки нет продвинутой системы типов, и кроме как нотацией их показать нельзя.
венгерская нотация применяется, в основном, как раз в C/C++.
NetBeans, Eclipse, VS прекрасно отображают тип переменной при наведении на нее курсора как в C, так и в C++. При чем одинаково хорошо как для встроенных типов, так и для определенных пользователем. В чём оно «сосёт»?
Во встроенных макросах и внешних препроцессорах. Ну да, внутри одного метода оно тип подсветит. А дальше — как бох на душу положит. Но проблема-то глубже. Сегодня VS в каком-то из Qt'шных методов упорно отображала возвращаемый тип как char*, хотя там была ни разу не char* и вообще inline. Поэтому если знаешь какую-то инфу, которую IDE может и не достать, нужно эту инфу тут же укатать в документацию или имена, чтобы с одного взгляда было понятно как и зачем это работает, и не требовалось читать исходник. Лучше пусть метод будет называться calculate_this_fuckin_variable_because_we_must_and_return_int (как в ObjectiveC), чем будет непойми что, работающее непойми как. Имхо.
Вернее — неправильным использованием венгерской нотации :).
У Спольски была статья про это.
У Спольски была статья про это.
Я соглашусь, что прямое указание типа у переменной даже в динамически типизируемых языках затея не самая здравая. Но нельзя же отрицать существование феномена.
Да, именно это и я имел ввиду выше.
local.joelonsoftware.com/mediawiki/index.php/Как_заставить_неправильный_код_выглядеть_неправильно
local.joelonsoftware.com/mediawiki/index.php/Как_заставить_неправильный_код_выглядеть_неправильно
Терпеть не могу (я бы даже сказал «люто бешено ненавижу и стремлюсь уничтожить») уродства типа этого:
$functionResult=idioticUglyFunction($stupidVariable),
а люблю вот это:
$function_result=beautiful_lovely_function($awesome_variable).
Как аргумент против коллег — любителей гадкого camelCase привожу документацию пхп: все стандартные функции в нижнем регистре и с подчеркиванием (*гадость из SPL стандартной не считать*).
PS.
Не холивара ради. Просто иррационально ненавижу одно и обожаю другое.
$functionResult=idioticUglyFunction($stupidVariable),
а люблю вот это:
$function_result=beautiful_lovely_function($awesome_variable).
Как аргумент против коллег — любителей гадкого camelCase привожу документацию пхп: все стандартные функции в нижнем регистре и с подчеркиванием (*гадость из SPL стандартной не считать*).
PS.
Не холивара ради. Просто иррационально ненавижу одно и обожаю другое.
Вот только пример с php неудачный. Уж у этих парней в названиях всякого хватает, и с подчеркиваниями, и без, и с логикой, и без неё.
Сохраните нервы — попробуйте не обращать внимания :)
SPL хотя бы имеет какой-то стандарт в отличии от функций, что уже подметили выше. Кроме того, не только то что в рамках SPL имеет camelCase нотацию, напрмиер, большинство ООП вещей в станадртной поставке и модулях. Да и тенденция в PHP явно к camelCase.
При всей моей любви к PHP на названия функций в этом языке не стоило бы ориентироваться. Взять хотя бы функции работы со строками — половина с нижним подчеркиванием, половина — без. Вот хотя бы например stripcslashes и strip_tags — в чем прикол? В одном случае есть подчеркивание, в другом — нет. Как раз таки SPL, как более поздняя разработка, сделана с учетом camelCase как и все прочие разработки Zend (в том числе и Zend Framework), а старые функции с плавающими пробелами — это дань прошлому, естественно сейчас никто ничего менять не будет, ибо надо сохранить совместимость с раними версиями.
Если не ошибаюсь, то имена ф-ций в пхп case-insensitive. И такие ф-ции, как stripcslashes, можно писать как stripCSlashes. Мне что-то подсказывает что так и задумывалось. Это еще больше подтверждает, что смотреть на именование ф-ций безсмысленно, там полная каша.
Там никак не задумывалось :)
Автор пехапе писал на коленке шаблонизатор для своего сайта, друзья присылали ему новые функции, он их просто добавлял в язык не задумываясь о какой-нибудь стандартизации. Потом язык стал популярным, и корявые имена функций исправлять было поздно.
Я надеялся, что с переходом на 5.3 или хотя бы на 6.0 функции упорядочат, но увы…
Автор пехапе писал на коленке шаблонизатор для своего сайта, друзья присылали ему новые функции, он их просто добавлял в язык не задумываясь о какой-нибудь стандартизации. Потом язык стал популярным, и корявые имена функций исправлять было поздно.
Я надеялся, что с переходом на 5.3 или хотя бы на 6.0 функции упорядочат, но увы…
Реквестирую тонны срача в комментариях к этому посту :)
Я использую camelCase для переменных, а для функций — under_score.
Например:
Например:
$myVariable = 123;
function print_variable($variableToPrint) {
echo $variableToPrint;
}
perldoc.perl.org/perlmodstyle.html — все просто, как написано, так и надо
От языка зависит.
Не люблю, когда передёргивают. При использовании подчёркиваний операторы отбиваются пробелами.
Таким образом:
Таким образом:
my_first_var = my_second_var - my_third_var и myFirstVar=mySecondVar-myThirdVar
Более того, при вызове принято так же отбивать пробелами скобки:
other_function( first_argument, second_argument );
С первым согласен, а вот со вторым не совсем. Например, Visual Studio сама по умолчанию будет убирать эти пробелы при каждом удобном случае.
Её не сложно отучить это делать…
Да, но зачем?
Это должна быть заранее оговорённая политика все команды, принимающей участие в разработке. Иначе почти каждый commit будет содержать автоправку от среды.
Не вижу особого смысла менять устоявшиеся настроки сред разработки. Основная масса разработчиков привыкает именно к ним.
Каждому новому сотруднику придётся их вдалбливать.
Это должна быть заранее оговорённая политика все команды, принимающей участие в разработке. Иначе почти каждый commit будет содержать автоправку от среды.
Не вижу особого смысла менять устоявшиеся настроки сред разработки. Основная масса разработчиков привыкает именно к ним.
Каждому новому сотруднику придётся их вдалбливать.
согласен. Хотя недавно встречал интересный пример кода, там пробелы стояли даже перед точкой с запятой, перед скобкой, после скобки, вот в таком стиле:
a = func ( param, param2 [ 5 ] );
это был ад… :)
a = func ( param, param2 [ 5 ] );
это был ад… :)
PEP8 не согласен с вами.
Я всегда обрамляю операторы пробелами, и никаких проблем с кодом в любой нотации. Хоть в эмо-стиле оформляй: mYfIrStVaR = mYsEcOnDvAr — mYtHiRdVaR
Во многих стайл гайдах и при использовании camelCase требуется отбивать операторы (а то и всё подряд) пробелами. А вот требований отбивать аргументы при декларировании/вызове как-то не встречалось кажется.
>… в языке Java и его младшей сестре JavaScript…
Кто-то ввел вас в заблуждение. Кроме 4-х одиаковых букв, между ними ничего общего.
Кто-то ввел вас в заблуждение. Кроме 4-х одиаковых букв, между ними ничего общего.
Сорри, не заметил что это перевод.
кроме того что это перевод, я в конце отметил что это разные вещи и автор заблуждается :)
Стоит ли автору верить?
Кстати, почему сестра? оО Какого рода слово «язык» — вроде б не женского?:)
for Java and its little sister JavaScript
Я думаю потому что Ява — она :)
В английском языке род имеют мужчины, женщины и морские корабли (которые женского рода). Всё остальное — среднего. Ввиду этого они привыкли обращаться с родами вольно.
В русском — да, «Java» женского рода, но «JavaScript» и «язык»-то — мужского.
Я бы, в общем, в русском переводе написал что-то вроде «Java и её младший брат JS». Хотя, видимо, это коробит только меня:)
В русском — да, «Java» женского рода, но «JavaScript» и «язык»-то — мужского.
Я бы, в общем, в русском переводе написал что-то вроде «Java и её младший брат JS». Хотя, видимо, это коробит только меня:)
Стиль кода общий (похожий).
Пишу проекты, построенные на технологии ajax, поэтому мне удобно писать всё, что относится к php, на under_score, а всё, что относится к js, на camelCase. Путаницы значительно меньше.
camelCase не так бьёт по читабельности, как расположение скобок в стиле BSD. Большой гемор потом помочь человеку найти или в чужом коде найти эти скобки: где потерялась.
Кроме того, с коллегами очень много споров было на тему аббревиатур при использовании верблюжьей нотации: как писать правильнее GenerateHTMLFromText или GenerateHtmlFromText, в итоге остановились на втором варианте, но чувство нерешенной проблемы все равно немного грызет.Для себя установил правило: если в аббревиатуре больше двух букв — прописной делать только первую букву (XmlRequest), если две буквы — оставлять обе прописные (ADUser).
В Pascal написание имен с использованием разных регистров имеет важное, но лишь декоративное назначение, так как компилятор между регистрами символов различий не делает.
//офтопик
откуда это вообще пошло «нижнее подчеркивание»? как можно ПОДчеркнуть выше?!!! О_о
откуда это вообще пошло «нижнее подчеркивание»? как можно ПОДчеркнуть выше?!!! О_о
Насколько я знаю, Java был спроектирован с нуля.
Легче поверить в общего предка человека и обезьяны чем в общий проязык Oak (оригинальное название Java) и LiveScript (оригинальное название JavaScript)
Первоначально язык JavaScript назывался LiveScript и предназначался как для программирования на стороне клиента, так и для программирования на стороне сервера (там он должен был называться LiveWire). На синтаксис оказали влияние языки Си и Java, и, поскольку Java в то время было модным словом, 4 декабря 1995 года LiveScript переименовали в JavaScript © Википедия.
Легче поверить в общего предка человека и обезьяны чем в общий проязык Oak (оригинальное название Java) и LiveScript (оригинальное название JavaScript)
Первоначально язык JavaScript назывался LiveScript и предназначался как для программирования на стороне клиента, так и для программирования на стороне сервера (там он должен был называться LiveWire). На синтаксис оказали влияние языки Си и Java, и, поскольку Java в то время было модным словом, 4 декабря 1995 года LiveScript переименовали в JavaScript © Википедия.
Привык уже использовать camelCase — спасибо Zend Framework. Так что насчет популярности подчеркивания среди php-программистов я бы поспорил…
Есть хорошая поговорка: De gustibus non est disputandum
Но нет-нет — да и появится очередная околохоливарная статься на Хабре…
Но нет-нет — да и появится очередная околохоливарная статься на Хабре…
о вкусах не спорят
Есть хороший топик на вики: en.wikipedia.org/wiki/List_of_Latin_phrases
Для незнающих латынь: о вкусах не спорят :)
>как писать правильнее GenerateHTMLFromText или GenerateHtmlFromText, в итоге остановились на втором варианте, но чувство нерешенной проблемы все равно немного грызет.
Вы выбрали вариант, который рекомендует МС: msdn.microsoft.com/en-us/library/ms229043.aspx
Для аббревиатур от 3х символов они рекомендуют писать только одну заглавную букву: Html, Olap, Ssrs, но DB, DX, MX и т.д.
Вы выбрали вариант, который рекомендует МС: msdn.microsoft.com/en-us/library/ms229043.aspx
Для аббревиатур от 3х символов они рекомендуют писать только одну заглавную букву: Html, Olap, Ssrs, но DB, DX, MX и т.д.
символом нижнего подчеркивания (_)А какое ещё подчёркивание бывает?
Возможно было подчеркивание, одно единственное, а потом появилось «надчеркивание». Но звучало неудобно, поэтому стало два подчеркивания — нижнее и верхнее)))
ptrue.livejournal.com/414510.html?thread=4433198#t4433198
У темы другая точка зрения на эту проблему:
tema.livejournal.com/151813.html?page=2
В целом термин «нижнее подчеркивание», который обозначает символ _ (против термина «подчеркивание», который обозначает действие) достаточно распространен и я считаю что его вполне можно использовать
Также данный стандарт используется в названиях стандартных функций PHP, и является очень популярным среди PHP-программистовБрехня. В PHP нет единого стиля (html_entity_decode, но htmlSpecialChars, прочем часто последнее пишут в одну строку), за что его и ругают.
верблюжья нотация является стандартом в языке Java и его младшей сестре JavaScriptJava и JavaScript не родственники, а однофамильцы. «JavaScript» — коммерческое название, его придумали маркетологи, тогда как раз Java популярность набирала дикими темпами.
в случае с нижним подчеркиванием и знаком «минус» выражение с первого взгляда вообще можно принять за одну переменную, однако подсветка синтаксиса может решить эту проблему.Нормальные люди решают эту проблему форматированием кода. Окружите минус пробелами и вы уже не сможете прочитать ту строку как одну переменную.
Ёпрст, сколько флейма. Используете рекомендации и стандарты, которые определены для вашего языка. Для шарпа, например, целый документ есть, в котором говорится, что и как нужно именовать и какой стиль использовать.
Camel Case является противоположностью английского, русского и многих других языков: в обычных языках предложение начинается с большой буквы, а все остальные слова пишутся строчнымиДорогой Искандер Гиниятуллин, в России принято писать с большой буквы не только слова в начале предложения.
использую в основном under_score, однако в циклах, где нужен счетчик — до сих пор использую i, j, k и им подобное.
Я за camelCase, он на целый байт меньше!
Статья ни о чем.
Хм. А я вот раньше тоже начинал переменную с префикса, указывающего на тип (string sUserName). Тут смысл был скорее (для меня) в том, чтобы набрав первую букву сразу отфильтровать выпадающий список по типу.
Однако потом как-то прочитал статью, что при нормальном именовании переменных без подобных «пояснений» должно все быть ясно. И на самом деле согласился. Глядя на свой код спустя… я обычно не испытываю проблем с пониманием. Даже вот не знаю. Скажет кто чего?
Однако потом как-то прочитал статью, что при нормальном именовании переменных без подобных «пояснений» должно все быть ясно. И на самом деле согласился. Глядя на свой код спустя… я обычно не испытываю проблем с пониманием. Даже вот не знаю. Скажет кто чего?
Найдите статью Джоэля Спольски о венгерской нотации. Варианты вроде sUserName — это профанация, на самом деле.
Сам не использую, стараюсь именовать так, чтобы было ясно, что там лежит.
Сам не использую, стараюсь именовать так, чтобы было ясно, что там лежит.
Но это Джоэль Спольски так считает.
Для переменных, типов венгерская нотация может и не подходит,
но мне удобно ее использовать для объектов интерфейса.
frmLogin, edtUserName, edtPassword, cmbHostName…
UserName := frmLogin.edtUserName.Text;
Вроде читабельно, можно быстро увидеть/разделить интерфейс от логики.
И это только имхо. И да, это Delphi :) Для других языков, как утверждает Джоэль Спольски, это не всегда подходит.
Для переменных, типов венгерская нотация может и не подходит,
но мне удобно ее использовать для объектов интерфейса.
frmLogin, edtUserName, edtPassword, cmbHostName…
UserName := frmLogin.edtUserName.Text;
Вроде читабельно, можно быстро увидеть/разделить интерфейс от логики.
И это только имхо. И да, это Delphi :) Для других языков, как утверждает Джоэль Спольски, это не всегда подходит.
Я считаю, что Спольски можно доверять. Он аргументированно рассказывает:)
Ну, для объектов интерфейса — да, может быть. Но я в таких случаях предпочитаю положить все такие объекты в запись (по терминологии Pascal), а потом обращаться как-то так:
Ну, для объектов интерфейса — да, может быть. Но я в таких случаях предпочитаю положить все такие объекты в запись (по терминологии Pascal), а потом обращаться как-то так:
passwd = form.passwd.value (это JS).Выше уже приводили ссылки, и если внимательно прочитать, что Джоэль пишет, то можно заметить: Джоэль за Венгерский для приложении и против Системного Венгерского.
Я же привожу пример, когда даже Системный Венгерский, имхо, вполне не плохо смотрится.
Я же привожу пример, когда даже Системный Венгерский, имхо, вполне не плохо смотрится.
Тип переменной — это не венгерская нотация. Плохо ли это? Да.
Содержимое переменной — это настоящая венгерская нотация. Хорошо ли это? Может быть.
Содержимое переменной — это настоящая венгерская нотация. Хорошо ли это? Может быть.
Вы абсолютно правы используя префиксы.
Иногда имени переменной не достаточно.
Одна сущность вполне может быть представлена в нескольких типах.
Пример:
string sPhoneNumber = editboxPhoneNumber.Text;
int nPhoneNumber = int.TryParse(sPhoneNumber);
Иногда имени переменной не достаточно.
Одна сущность вполне может быть представлена в нескольких типах.
Пример:
string sPhoneNumber = editboxPhoneNumber.Text;
int nPhoneNumber = int.TryParse(sPhoneNumber);
Точно! Именно у него я вычитал подобное…
Довольно странно, что в переводе (и в оригинале) фигурирует, цитирую:
Знак минус — есть именно знак минус.
Вы уж простите, но во всех языках используется дефис (черточка). Несмотря на то, что его и называют от природы hyphen-minus (0x2D), в переводе лучше использовать термин «дефис».
Очевидно, что camel case читается лучше: в случае с нижним подчеркиванием и знаком «минус» выражение с первого взгляда [...]
Знак минус — есть именно знак минус.
Вы уж простите, но во всех языках используется дефис (черточка). Несмотря на то, что его и называют от природы hyphen-minus (0x2D), в переводе лучше использовать термин «дефис».
в Objective-c всегда использовал camelCase
и сейчас under_score выглядит как вырви глаз 0_о
хотя когда писал на php вроде пользовался и не жаловался)
все таки о вкусах не спорят
и сейчас under_score выглядит как вырви глаз 0_о
хотя когда писал на php вроде пользовался и не жаловался)
все таки о вкусах не спорят
есть еще BLONDYSTYLE в SQL можно встретить
и
______leading_underscore_style
и
______leading_underscore_style
Лично я отдаю предпочтение уже существующим стилевым стандартам:
В последнее время искал офоциальный style guide для C#, но так и не нашёл того, что хотел, в той форме, что хотел, поэтому использую свой собственный набор правил.
Использование подобных стилевых спецификаций создаёт ощущение некой гармонии при написании когда. Просто следуешь наиболее авторитетным стандартам, и не нужно ничего придумывать. А когда создаёшь свой собственный стиль — это немного отвлекает от реализации задачи.
- Google C++ Style Guide
- Google JavaScript Style Guide
- Google XML Document Format Style Guide
- Zend Framework Coding Standard for PHP
В последнее время искал офоциальный style guide для C#, но так и не нашёл того, что хотел, в той форме, что хотел, поэтому использую свой собственный набор правил.
Использование подобных стилевых спецификаций создаёт ощущение некой гармонии при написании когда. Просто следуешь наиболее авторитетным стандартам, и не нужно ничего придумывать. А когда создаёшь свой собственный стиль — это немного отвлекает от реализации задачи.
Посмотрите наг гайд по С# комманды RSDN, в принципе он неплох: www.rsdn.ru/article/mag/200401/codestyle.XML
Хороший материал, спасибо. Единственное, что они упустили, — нет примеров if со сложным condition. Например, верно ли так:
Как тут стоит записывать: по условию на строку, по длине строки (кстати, об этом ничего не сказано) или как-то ещё?
if (false == _processing
&& true == _finished) // 4 spaces
{
// ...
}
Как тут стоит записывать: по условию на строку, по длине строки (кстати, об этом ничего не сказано) или как-то ещё?
Ну, конкретно тут, я думаю:
if ( _finished && !_processing )
{
//…
}
В более сложных случаях я объявляю перед if пару промежуточных переменных, в которых вычисляю части сложного условия, а выражение в if все-равно свожу к двум-трем переменным. У такого подхода целая куча плюсов:
1. Легче читать код, когда видишь названия этих промежуточных переменных
2. Легче отлаживать — можно просмотреть значения этих переменных
3. Короткие выражения в блоке if — более понятно, что происходит.
Суть этого подхода я вычитал в «Совершенном коде» Макконела.
if ( _finished && !_processing )
{
//…
}
В более сложных случаях я объявляю перед if пару промежуточных переменных, в которых вычисляю части сложного условия, а выражение в if все-равно свожу к двум-трем переменным. У такого подхода целая куча плюсов:
1. Легче читать код, когда видишь названия этих промежуточных переменных
2. Легче отлаживать — можно просмотреть значения этих переменных
3. Короткие выражения в блоке if — более понятно, что происходит.
Суть этого подхода я вычитал в «Совершенном коде» Макконела.
Венгерская нотация — fffuuu :)
А так CamelCase самое оно, все методы и классы с заглавной буквы в C#, и методы с маленькой буквы — в JavaScript. Все переменные всегда с маленькой, и для приватных переменных — символ подчеркивания в самом начале.
Тем не менее названия юнит-тестов называются, скажем так, гибридным образом, например:
«ActionInvoker_ShouldBe_AbleToBe_Created()»
или
" ActionInvoker_Should_Set_The_ActionReturnValue_As_ViewModel_When_It_IsObject_And_Not_An_ActionResult()"
А так CamelCase самое оно, все методы и классы с заглавной буквы в C#, и методы с маленькой буквы — в JavaScript. Все переменные всегда с маленькой, и для приватных переменных — символ подчеркивания в самом начале.
Тем не менее названия юнит-тестов называются, скажем так, гибридным образом, например:
«ActionInvoker_ShouldBe_AbleToBe_Created()»
или
" ActionInvoker_Should_Set_The_ActionReturnValue_As_ViewModel_When_It_IsObject_And_Not_An_ActionResult()"
Russian0Perfo0Case
Предлагаю также обсудить, едят ли курицу руками.
Я ем только вилкой и ножиком, чем вызываю бешеное негодование всех родственников. о_0
Хех, заюавно, я обычно тоже, но в итоге вызываю негодование у себя самого, после чего забиваю, и беру руками :)
Ну, у меня почему-то они рассуждают так: «Раз человек не хочет брать курицу руками, значит у него не все в порядке с головой и его надо срочно сдать в дурку на лечение».
А меня просто бесит брать жирную куру руками — терпеть это не могу. Цивильно и культурно ем вилкой и ножиком. Но их это раздражает.
А меня просто бесит брать жирную куру руками — терпеть это не могу. Цивильно и культурно ем вилкой и ножиком. Но их это раздражает.
Ну и заодно, что было раньше — яйцо или курица, чего уж там.
Хо-хо, не все так просто. Лично для себя выяснил что курицу удобней всего есть двумя вилками.
Меня лично раздражает именование переменных типа event5 — ничего не понятно из названия.
С другой стороны, верблюжья нотация является стандартом в языке Java и его младшей сестре JavaScript, хотя ее можно встретить также и в других местах. <\i>
Почему с другой? Параграф выше гласит, что доминирующим стандартом для C/C++ (я бы еще добавил Objective-C) является верблюд и потом пишите что с «другой стороны». По тексту это значит что JAVA должен отличаться, но это не так. Более того в Java очень много взято из C++ и Delphi (источник Bruce Eckel «Thinking in Java»). Так что не удивительно что в нем приняты такие нотации.
В общем текст ни о чем, а лично мое мнение, что нижнее подчергивание и приватные переменные и функции, который начинаются с нижнего подчеркивания — это все архаизмы, которые каким-то образом до сих пор живы.
Почему с другой? Параграф выше гласит, что доминирующим стандартом для C/C++ (я бы еще добавил Objective-C) является верблюд и потом пишите что с «другой стороны». По тексту это значит что JAVA должен отличаться, но это не так. Более того в Java очень много взято из C++ и Delphi (источник Bruce Eckel «Thinking in Java»). Так что не удивительно что в нем приняты такие нотации.
В общем текст ни о чем, а лично мое мнение, что нижнее подчергивание и приватные переменные и функции, который начинаются с нижнего подчеркивания — это все архаизмы, которые каким-то образом до сих пор живы.
camelCase — верблюжий чемодан =)))
Если бы IDE научились смягчать подчеркивание в именах:
Хотя, к сожалению, часто приходится иметь дело с уже готовым стилем, где вводить свои порядки как-то неаккуратненько.
Хотя, к сожалению, часто приходится иметь дело с уже готовым стилем, где вводить свои порядки как-то неаккуратненько.
лично я юзаю и первый, и второй способ. Утилитки с общим API у меня пишутся на С++, причём общее API используется в виде классов, а само действие утилиты больше написано в процедурном стиле. Соответственно, классовая часть Кэмелом, процедурная — с подчёркиванием. Трудность чтения названия на тамошних размерах пока не пугает, но зато сам себе в голове отделяю вечное (общий API) от бренного (подробности его использования в данном конкретном смысле)
Следующий пост про расстановку скобок? Какие стандарты в проекте определены так и надо писать.
Про скобки уже было: habrahabr.ru/blogs/php/37831/ :)
Я бы ещё добавил, что андерскоры удлиняют длину строки. Что усложняет ситуацию, если на эту самую длину в соглашениях установлен лимит.
А я не парюсь, в большинстве случаев нотацию диктует используемый фреймворк. И лучше ей следовать, не то зоопарк гарантирован.
Юзаю везде under_score, так повелось еще с институтского с++, но когда изучал Livestreet оценил венгерскую нотацию с кэмел кейзом — очень удобно разбираться в чужом коде с ней.
Мде… Разве не логично писать так, как диктуют стайлгайды к конкретному языку?..
в camelCase раздражает, когда в имени переменной есть предлог или аббревиатура. как в таком случае поступать? например как написать «RGB to color» или «is GPS connected» и в таком духе?
В руби:
обычные переменные: my_super_var
контанты и имена классов/модулей: MySuperClass, MySuperConst
обычные переменные: my_super_var
контанты и имена классов/модулей: MySuperClass, MySuperConst
Добавлю и от себя пять копеек. Одно из «преимуществ» 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 )
А помоему пофиг как выглядит кодинг-стандарт — главное что б он был и его придерживались все участники проекта.
>только в качестве первого слова использую сокращенный тип переменной (bProductActive, iProductsCount, sUserName)
Я использую префиксы 'm' для полей класса и 'k' для констант.
Я использую префиксы 'm' для полей класса и 'k' для констант.
в Ruby например от первой буквы зависит будет ли у вас это константа (класс) или переменная, CONST = 6 или const = 6; const =+ 1; можно
Классы так же по соглашению именуются NewsController, но методы и переменные under score hello_kitty
Этого же я придерживаюсь в PHP (CodeIgniter framework) и всегда против Camel Case так как в речи у нас всегда между словами есть пробелы (ну может кроме в тайской речи)
Классы так же по соглашению именуются NewsController, но методы и переменные under score hello_kitty
Этого же я придерживаюсь в PHP (CodeIgniter framework) и всегда против Camel Case так как в речи у нас всегда между словами есть пробелы (ну может кроме в тайской речи)
Использование camelCase в Eclipse дает несравненое преимущество по сравнению с under_score в плане автодополнения. Например, если у вас есть класс MyAwesomeMegaClass, то достаточно будет набрать в эдиторе MAMC, нажать ctrl+space и IDE автоматически найдет все совпадения названий по camelCase и скорее всего единственным совпадением будет имя вашего класса. То же самое работает для переменных и методов, что очень сильно ускоряет кодописание.
Глупо раздувать холивар из ничего. У каждого приличного языка есть правила именования.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
camelCase против under_score