Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 90
number_favorite_news для переменных
numberFavoriteNews для функций
numberFAVORITENEWS для классов
Привык так :)
numberFavoriteNews для функций
numberFAVORITENEWS для классов
Привык так :)
Как предпочитаю на Си/Java:
this_is_variable
ThisIsFunction()
this_is_variable
ThisIsFunction()
Для Java есть оффициальные соглашения об именовании/
В java есть функции?
первый вариант для всего — нравится также третий, но в текущем проекте начал с первого, поэтому выдерживаю стилистику :)
ClassName
class_method
local_var
@object_var
@@class_var
$global_var
Ruby
class_method
local_var
@object_var
@@class_var
$global_var
Ruby
Опросник с подвохом)
1. Если речь идет о локальных переменных — однозначно my_local_variable
3. Глобалы, имена классов — MyVariable, MyFooClass
4. Константы — MY_CONSTANT
Вроде ничего не забыл?
1. Если речь идет о локальных переменных — однозначно my_local_variable
3. Глобалы, имена классов — MyVariable, MyFooClass
4. Константы — MY_CONSTANT
Вроде ничего не забыл?
className — классы
$iCount — переменные
$CONF — константы
^getVar[] — методы
field_name — поля форм, БД и переменные внешних языков (js например)
Parser 3
$iCount — переменные
$CONF — константы
^getVar[] — методы
field_name — поля форм, БД и переменные внешних языков (js например)
Parser 3
Интересно, а длина имени переменной влияет на скорость выполнения скрипта? Интересует именно ActionScript.
Так же как длинна обеденного перерыва, на вкус обеда.
ну можно привести пример в котором влияет) когда там работа с какими нибудь eval конструкциями зацикленными, так, чтобы постоянно приходилось плодить экземпляры парсера на каждом проходе. тогда действительно повляет длина вводимого кода. но это гон ведь какой-то получится)
Для public методов и полей и для не финализированных protected разница есть, так как флеш плейер для оперирования ими использует стринговые хеши, их имена сохраняются в swf и swc файлах, сохраняются и при декомпиляции.
Для локальных переменных, private и final protected методов используется другой инструментарий, который оперирует численным дескриптором ссылки на объект — работает быстрее, стринговое имя уничтожается при компиляции и скорость и вес конечного приложения не зависит от длинны исходно имени.
Ты врятли поймешь разницу между работой хеша из одного символа и из сотни символов, она есть, но со спокойной душой пренебрегай ею. На любой платформе
Для локальных переменных, private и final protected методов используется другой инструментарий, который оперирует численным дескриптором ссылки на объект — работает быстрее, стринговое имя уничтожается при компиляции и скорость и вес конечного приложения не зависит от длинны исходно имени.
Ты врятли поймешь разницу между работой хеша из одного символа и из сотни символов, она есть, но со спокойной душой пренебрегай ею. На любой платформе
Идите почитайте срочно об интерпретации, компиляции и выполнение программ
Стиль именования зависит от языка, на котором пишешь в данное время.
Я так думаю, стиль переменных зависит от соглашений по форматированию кода, принятого в текущем проекте команды.
Уточню. Даже если вы привыкли именовать переменные, допустим, $this_is_var, но стиль проекта $thisIsVar, то, как ни крути, вам придется принять общие условия.
И да, я придерживаюсь стиля №3, где это возможно.
Уточню. Даже если вы привыкли именовать переменные, допустим, $this_is_var, но стиль проекта $thisIsVar, то, как ни крути, вам придется принять общие условия.
И да, я придерживаюсь стиля №3, где это возможно.
Стиль проекта, конечно, рулит, но стиль номер три можно было придумать только с большого бодуна. Ибо он, во-первых, непоследователен, а во-вторых плохо читается (нет промежутков между словами, достижения XVII века побоку).
Сколько людей — столько мнений. :)
Мне удобнее именовать так. И особенно удачно в сочетании с некими префиксами, например, $countApples = 0 либо, если устанавливаем какой-то флаг, $boolAppleGood = false
И так далее.
Разумеется, я не истина в последней инстанции и мой стиль, возможно, — ущербен. Однако никто не жаловался до сих пор. :)
Мне удобнее именовать так. И особенно удачно в сочетании с некими префиксами, например, $countApples = 0 либо, если устанавливаем какой-то флаг, $boolAppleGood = false
И так далее.
Разумеется, я не истина в последней инстанции и мой стиль, возможно, — ущербен. Однако никто не жаловался до сих пор. :)
зато снижается общий визуальный шум, уменьшается длина названий переменных.
и по-моему это как раз читабельнее — глаза скачут по большим буквам и слова рядом быстрее распознаются, нужно меньше напрягаться. уж если использовать «_» то писать тогда так: int_The_Good_Var
и по-моему это как раз читабельнее — глаза скачут по большим буквам и слова рядом быстрее распознаются, нужно меньше напрягаться. уж если использовать «_» то писать тогда так: int_The_Good_Var
$var_name
className
classMethod
$classVar
fuctionName
$functionArgument
CONST
$if_var — переменные условия
$_private
className
classMethod
$classVar
fuctionName
$functionArgument
CONST
$if_var — переменные условия
$_private
если что-то используется во многих местах (глобальные переменные, поля различных структур), то полное имя в стиле:
Если переменная локальная, то короткие имена. Обычно, смысл понятен из контекста. Если не понятен, то короткое имя с комментарием.
Конечно, хотелось бы писать длинные имена в стиле:
который подчёркивает то, что работа идёт с целостным объектом. Но проблема в том, что не все люди способны быстро разбирать такой текст на слова.
диктует странные правила для переменных, в которых есть сокращения. Получается нечто вроде:
Оба варианта плохо читаются, imho. Нужно затрачивать дополнительные мозговые усилия, чтобы правильно воспринять сокращение в первом случае, или чтобы найти следующее за сокращением слово во втором.
Ну, и естественно, на идентификаторы с подчёркиваниями можно натравить spell_checker.
the_var the_function the_type_t the_class_c
Если переменная локальная, то короткие имена. Обычно, смысл понятен из контекста. Если не понятен, то короткое имя с комментарием.
Конечно, хотелось бы писать длинные имена в стиле:
someverylongname
который подчёркивает то, что работа идёт с целостным объектом. Но проблема в том, что не все люди способны быстро разбирать такой текст на слова.
someVeryLongName
диктует странные правила для переменных, в которых есть сокращения. Получается нечто вроде:
numOfTcpBins / numOfTCPBins makeSdlScene / makeSDLScene
Оба варианта плохо читаются, imho. Нужно затрачивать дополнительные мозговые усилия, чтобы правильно воспринять сокращение в первом случае, или чтобы найти следующее за сокращением слово во втором.
Ну, и естественно, на идентификаторы с подчёркиваниями можно натравить spell_checker.
sNameOfVariable — для строковых переменных
iNameOfVariable — для числовых и т.д.
iNameOfVariable — для числовых и т.д.
Сразу видно своих людей в толпе.
Миша почти всех подсадил :)
Миша почти всех подсадил :)
Кодирование типа переменной в имени — Бейсиком отдает имхо :) А если серьезно, работал я в одном проекте, где в требованиях к имени переменных было указывать тип (a, v, s, f), тремя символами название модуля и потом уже имя переменной (функции). Получались довольно забавно: $v_cmn_ThisFuckingvariable хотя и не лишено некоторого смысла.
Чем бы оно ни отдавало, но глядя в код я сразу вижу, что должно содержаться в этой переменной. И какие преобразования я могу с этим делать. Это действительно удобно, особенно когда лезешь в свой старый код. И к этому быстро привыкаешь.
Вобще в программировании важно выработать для себя определенные правила оформления кода. И приучить себя ими пользоваться. Тогда не испытываешь никаких проблемы разбирая свое же творение n-годичной давности :)
Вобще в программировании важно выработать для себя определенные правила оформления кода. И приучить себя ими пользоваться. Тогда не испытываешь никаких проблемы разбирая свое же творение n-годичной давности :)
То есть вы принципиальный противник менять тип переменной «на лету»?
Не совсем. Иногда это требуется, но все-таки я стараюсь, что бы в переменной $sMyString была строка и только, в $dtMyDate — дата и т.д. Так значительно проще и мне и тому, кому, возможно, придется в моем коде разбираться.
Если тип переменной заранее не известен или изменится, то это $uVariable (u — unknown)
Если тип переменной заранее не известен или изменится, то это $uVariable (u — unknown)
а зачем? вам достаточно часто приходится это делать?
имхо вообще этого нужно избегать, чтобы не запутывать код.
в пхп например, использовать префиксы типов для переменных очень удобно, их мало:
i=int, f=float, fn=function(для коллбэков и динамических вызовов), s=string, o=object, a=array, h=hash(по вкусу), r=resource, b=bool, m=mixed(как раз, когда заранее не известно)
kulikoff писал, что использует u=unknown, однако mixed используется в мануале + например, в эклипсе, поэтому более предпочтителен
не понимаю, почему ветку минусуют, префиксы в языках типа пхп повышают читабельность кода. я тоже сначала косо смотрел, потом когда попробовал, привык мгновенно и потом оценил эффект.
имхо вообще этого нужно избегать, чтобы не запутывать код.
в пхп например, использовать префиксы типов для переменных очень удобно, их мало:
i=int, f=float, fn=function(для коллбэков и динамических вызовов), s=string, o=object, a=array, h=hash(по вкусу), r=resource, b=bool, m=mixed(как раз, когда заранее не известно)
kulikoff писал, что использует u=unknown, однако mixed используется в мануале + например, в эклипсе, поэтому более предпочтителен
не понимаю, почему ветку минусуют, префиксы в языках типа пхп повышают читабельность кода. я тоже сначала косо смотрел, потом когда попробовал, привык мгновенно и потом оценил эффект.
Ага, точно. Но удобно ведь!
Если из названия переменной неясно что там хранится внутри — это плохое название, подумайте ещё. А в типах компилятор/интерпретатор разберутся лучше вас. Исключение — недоязыки типа PHP, где из-за идиотских попыток «облегчить» жизнь программистам на интерпретатор нельзя положиться.
ок, возьмем идентификатор. обычно пишут somethingId. обычно это int, но в некоторых случаях это может быть строка, например если это id сессии. однако, например у сессий селениума в старых версиях id сессии был целым числом, потом поменялся на md5-хэш.
итак, варианты:
— sessionId — когда я вижу это в коде, я сходу не понимаю что это, это может быть чем угодно
— sessionIdHash — md5-хэш? или ассоциативный массив с id'ами сессий?
— iSessionId, sSessionId — сразу ясно, не нужно вдумываться
при чем тут интерпретатор? префикс на него все равно не влияет, а код читают и поддерживают люди.
итак, варианты:
— sessionId — когда я вижу это в коде, я сходу не понимаю что это, это может быть чем угодно
— sessionIdHash — md5-хэш? или ассоциативный массив с id'ами сессий?
— iSessionId, sSessionId — сразу ясно, не нужно вдумываться
при чем тут интерпретатор? префикс на него все равно не влияет, а код читают и поддерживают люди.
— sessionId — когда я вижу это в коде, я сходу не понимаю что это, это может быть чем угодноА оно вам важно? Думаю для понимания логики в 99% случаев — нет. А если где-то возникнет путаница, компилятор или интереретатор ошибку отловят.
Случаются такие казусы не так часто, а мусор для защиты от них вы создаёте по всему проекту.
колеблюсь между первым и вторым
1й — ПХП
2й — имена классов
3й — джава
4й — больше Си
2й — имена классов
3й — джава
4й — больше Си
Везде по разному. Зависит от языка в котором применяется и от роли переменной. например обычно у паблик и привэйт членов класса разные способы именования и т.п.
Название переменной должно нести в себе информацию, которую другим путём получить сложно. Приватные/публичные переменные, имена классов и констант — всё это приличные редакторы могут выделить цветом/шрифтом без всяких усилий с вашей стороны и они сделают это правильнее (вам никогда не случалось переносить переменную из приватной в публичную часть?). Зачем эту информацию дублировать???
т.е. вы призываете обзывать переменные как попало, а редактор пускай их цветом выделяет? На мой взгляд намного удобнее если в названиях переменных придерживаться определенного стиля, иначе начинается бардак в коде.
Я призываю не слишком усердстовать в этом процессе. И да — в идеале нужно бы все переменные называть одинаково. Но так как мы редко начинаем с нуля — то переносим в новые проекты старые привычки. Ничего плохого в этом нет, (кто-то верит в Иисуса, кто-то в Будду) — но нужно понимать что никакой объективной потребности в этих правилах наименования нет…
Как уже выше замечалось, программисты большую часть времени читают код, а не пишут. Если каждый будет использовать свой стиль именования переменных/фуркций/классов и т.п., то в итоге на разбор работы системы, которую писали, например, человек 5 потратится намного больше времени, это мое личное мнение.
Давайте не будем больше спорить, а то это какой-то холивар получается :)
Давайте не будем больше спорить, а то это какой-то холивар получается :)
юзаю 3ий для Ява
и его же для ПХП (ибо использую Зендовсие договоренности, а они почти точь точь с явой совпадают =) )
и его же для ПХП (ибо использую Зендовсие договоренности, а они почти точь точь с явой совпадают =) )
как лучше именовать множественные значение
например фото пользователей: photosOfUsers || userPhotos || usersPhotos?
часто встречается еще такое лингвистическое именование: aName (добваление неопр. артикля)
например фото пользователей: photosOfUsers || userPhotos || usersPhotos?
часто встречается еще такое лингвистическое именование: aName (добваление неопр. артикля)
А смотря какой смысл вы вложить хотите в имя переменной. Если это множество состоящие из 'фотография пользователя', то user photos. Если это множество 'фотография пользователей', то users photos. Если это множество фотографий множества пользователей, то photos of users. Хотя, тут надо спросить более сведующего в языке человека. Но, по идее, так должно быть.
А вообще, самый удобный язык для программирования — это Эсперанто. Там полная определённость со всеми падежами, числами и структурой словосочетаний.
А вообще, самый удобный язык для программирования — это Эсперанто. Там полная определённость со всеми падежами, числами и структурой словосочетаний.
aName, anApplication — принято в Borland Pascal для именования параметров методов/функций :)
поля объектов именуют с заглавной буквы F.
А в C#, например, поля объектов начинаются с _.
поля объектов именуют с заглавной буквы F.
А в C#, например, поля объектов начинаются с _.
Конечно только «кемел-стайл» (венгерская нотация?), тоесть вариант 3. PHP/Java
C++
class CSomeClass;
void SomeFunction();
int someVariable;
class CSomeClass;
void SomeFunction();
int someVariable;
Зависит от:
1) языка разработки;
2) стиля программирования в конкретном проекте.
Для .NET, JavaScript, C++: camel case.
Для Perl — underscore_separated.
1) языка разработки;
2) стиля программирования в конкретном проекте.
Для .NET, JavaScript, C++: camel case.
Для Perl — underscore_separated.
вот еще размышления по теме:
local.joelonsoftware.com/mediawiki/index.php/Как_заставить_неправильный_код_выглядеть_неправильно
local.joelonsoftware.com/mediawiki/index.php/Как_заставить_неправильный_код_выглядеть_неправильно
lf_some_local_var
lt_some_local_tab — локальный массив
gf_some_global_var — глобальная переменная
p_something, so_something — параметры
if_some_var — параметры функции
ef_some_var — результаты функции
пирожок тому, кто угадает язык программирования :)
lt_some_local_tab — локальный массив
gf_some_global_var — глобальная переменная
p_something, so_something — параметры
if_some_var — параметры функции
ef_some_var — результаты функции
пирожок тому, кто угадает язык программирования :)
class_name
method_name
function_name
$var_name
PHP
method_name
function_name
$var_name
PHP
для понятного кода:
$iInteger — целое чило
$fFloat — число с плавающей точкой
$bBoolean — булева переменная
и т.д.
+ комменты, и будет вам счастье )
ну, т.е. «префикс» перед переменной должен совпадать с ее типом
p.s.: maxshopen, Вас поддерживаю. к сожалению, заметил на хабре тенденцию к ненависти парсера )
$iInteger — целое чило
$fFloat — число с плавающей точкой
$bBoolean — булева переменная
и т.д.
+ комменты, и будет вам счастье )
ну, т.е. «префикс» перед переменной должен совпадать с ее типом
p.s.: maxshopen, Вас поддерживаю. к сожалению, заметил на хабре тенденцию к ненависти парсера )
это типа венгерской нотации что ли? Забудьте про нее. Вас научили совершенно не тому, для чего она была создана :)
Подумайте о логике!
Вам легко разбирать чужие коды, где переменные именованы по типу $nlo1 и $nlo2?
или Вы так и пишите? оО
Или, к примеру, $my_variable_first_hash и $my_variable_first_integer.
не проще будет разобраться в переменных типа $hFirst и $iFirst?
Вам легко разбирать чужие коды, где переменные именованы по типу $nlo1 и $nlo2?
или Вы так и пишите? оО
Или, к примеру, $my_variable_first_hash и $my_variable_first_integer.
не проще будет разобраться в переменных типа $hFirst и $iFirst?
Не проще. Переменные следует именовать согласно их назначению, и префикс или суффикс, несущий в себе тип переменной — это последнее, что я хочу знать об этой переменной.
Повторю еще раз: венгерка была придумана для указания НЕ ТИПА переменной, а для указания ВИДА переменной, т.е. СУТИ того значения, которое содержится в переменной. Почитайте [дважды] статейку «Making Wrong Code Look Wrong» за авторством Joel Spolsky — Вы всё поймете и перестанете писать эту ересь в коде ;-)
Повторю еще раз: венгерка была придумана для указания НЕ ТИПА переменной, а для указания ВИДА переменной, т.е. СУТИ того значения, которое содержится в переменной. Почитайте [дважды] статейку «Making Wrong Code Look Wrong» за авторством Joel Spolsky — Вы всё поймете и перестанете писать эту ересь в коде ;-)
private $m_Member;
function ($p_Parameter)
{
$l_Local = $p_Parameter;
}
function ($p_Parameter)
{
$l_Local = $p_Parameter;
}
Для Javascript numberFavoriteNews
Для PHP number_favorite_news
Для PHP number_favorite_news
C++:
class SomeClass
{
public:
void Method(int someArg)
{
int someLocal;
}
private:
int _somePrivate;
};
class SomeClass
{
public:
void Method(int someArg)
{
int someLocal;
}
private:
int _somePrivate;
};
C++
NumberFavoriteNews для имени класса
numberFavoriteNews для публичных членов класса
numberFavoriteNews_ для защищенных членов класса
NUMBER_FAVORITE_NEWS для констант
Object Pascal
TNumberFavoriteNews для имени класса
NumberFavoriteNews для публичных членов класса
FNumberFavoriteNews для защищенных членов класса
NUMBER_FAVORITE_NEWS для констант
NumberFavoriteNews для имени класса
numberFavoriteNews для публичных членов класса
numberFavoriteNews_ для защищенных членов класса
NUMBER_FAVORITE_NEWS для констант
Object Pascal
TNumberFavoriteNews для имени класса
NumberFavoriteNews для публичных членов класса
FNumberFavoriteNews для защищенных членов класса
NUMBER_FAVORITE_NEWS для констант
в Лиспах и XSLT:
foo-bar
в языках с C-style синтаксисом:
fooBar
в Хаскеле и Окемле:
fb (а когда нехорошее настроение, называю одну переменную f, вторую ck, и перемножаю их вот так: f*ck)
foo-bar
в языках с C-style синтаксисом:
fooBar
в Хаскеле и Окемле:
fb (а когда нехорошее настроение, называю одну переменную f, вторую ck, и перемножаю их вот так: f*ck)
для Java:
ClassName
varMane
methodName()
CONST_NAME
ClassName
varMane
methodName()
CONST_NAME
ВЕРБЛЮД, только верблюд + BSD!
Наверное, все-таки индивидуальный стиль диктуется первым «серьезно используемым» в работе языком. По своему опыту: писал на яве, сейчас программировать практически перестал, иногда приходится писать скрипты на питоне, и при их написании «непроизвольно» применяю java-оформление. Конечно лишь в тех случаях, когда скрипт пишется для себя, а не «наружу».
классы — MyClass
переменные — myVar
private поля класса — _myField
методы — MyMethod
интерфейсы — IMyInterface
свойства — MyProperty
константы — MY_CONSTANT
язык — C#
так имхо и читать удобно и неразберихи не будет
переменные — myVar
private поля класса — _myField
методы — MyMethod
интерфейсы — IMyInterface
свойства — MyProperty
константы — MY_CONSTANT
язык — C#
так имхо и читать удобно и неразберихи не будет
классы — Some_MySuperClass
методы классов — someSuperMethod
Переменные:
строковые, числовые и булевые — some_value
массивы — aSomeArray
объекты — oSomeObject
Теперь уже знаю, что для обозначения объектов и массивов следовало бы использовать другие буквы, но учить было некому и потому придумал себе сам такой стиль. удобно )
методы классов — someSuperMethod
Переменные:
строковые, числовые и булевые — some_value
массивы — aSomeArray
объекты — oSomeObject
Теперь уже знаю, что для обозначения объектов и массивов следовало бы использовать другие буквы, но учить было некому и потому придумал себе сам такой стиль. удобно )
Классы — MyClass
Методы — MyClassMethod
Тесты к методам — MyClassMethod_SomethingMustHappenTest (где SomethingMustHappen — краткое описание некоего условия, проверяемого тестом).
Переменные — value, justValue, someValue и так далее. Никаких венгерских нотаций. То же самое касается массивов и других объектов, помимо простых переменных. Бывает изредка экземпляры классов начинаются с «o» или obj (а ля oSomething или objSomething).
Ну и, имея в виду то, что код я сам не пишу уже несколько лет :), надо думать ребята из технологического направления еще что-то напридумывали. Но базовые правила соблюдаются и проверяются fxCop'ом.
P.S. Да, языки C#, JavaScript, ActionScript 3.0.
Методы — MyClassMethod
Тесты к методам — MyClassMethod_SomethingMustHappenTest (где SomethingMustHappen — краткое описание некоего условия, проверяемого тестом).
Переменные — value, justValue, someValue и так далее. Никаких венгерских нотаций. То же самое касается массивов и других объектов, помимо простых переменных. Бывает изредка экземпляры классов начинаются с «o» или obj (а ля oSomething или objSomething).
Ну и, имея в виду то, что код я сам не пишу уже несколько лет :), надо думать ребята из технологического направления еще что-то напридумывали. Но базовые правила соблюдаются и проверяются fxCop'ом.
P.S. Да, языки C#, JavaScript, ActionScript 3.0.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ваш стиль именования переменных