DmG 13 июн 2012 в 07:07

В каком стиле вы называете переменные и функции в своих проектах?

1 мин

4.3K

Программирование * IT-стандарты * Веб-разработка *

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

DmG 13 июн 2012 в 07:09

Если вы выбрали последний вариант, то буду очень признателен, если укажете в каких именно ЯП какой стиль, спасибо :)

Zelgadis 13 июн 2012 в 08:09

camelCase — obj-c/c++
under_score — Ruby, CoffeeScript, Javascript

nochnoy 13 июн 2012 в 08:43

Странно, я думал для ява-подобных языков стандартом является именно camelCase.

Zelgadis 13 июн 2012 в 08:58

ответил ниже.

TheShock 13 июн 2012 в 08:49

Зачем издеваться при помощи under_score над JavaScript то? Там есть свой стандарт кодирования.

Zelgadis 13 июн 2012 в 08:56

У меня 100% гарантия того, что мой код никто кроме меня не прочитает и не увидит. under_score читается легче чем camelCase, это в obj-c его легко читать из-за именованных аргументов.

QCasper 13 июн 2012 в 09:45

Эгоистично…

Zelgadis 13 июн 2012 в 16:57

:) Если пишу код который кто-то другой может видеть — пишу как положено, но на JS'e я не пишу почти, а в кофе пишу как на руби.

Paulus 13 июн 2012 в 20:05

IMHO отсутствует главный вариант: в стиле заданном в документации проекта. На моей памяти такие вопросы решались иногда простым голосованием ;)
А вариантов еще много, всякие _x, m_x и X вполне себе могут быть в одном проекте, и это не зависит от языка

1101_debian 13 июн 2012 в 07:14

getItem — C/C++/ObjC
get_item — Ruby

IgorMats 13 июн 2012 в 07:18

Чаще всего lowerCase camel notation. Также все время очень хочется применять ее в PHP проектах, но там принята underline notation.

DmG 13 июн 2012 в 07:23

Вот-вот, я часто пишу на PHP и Java и… просто разрываюсь, как называть.

MaxRaccoon 13 июн 2012 в 07:31

В самом PHP, да. Но это не мешает разработчикам (например ZendFramework, Symfony, Doctrine) использовать lowerCamelCase. Не понимаю, почему это мешает Вам?

arturich 13 июн 2012 в 08:00

Для начала — пишу не для холивара. Сам пишу на php. Могу сказать, что не знаю что именно там принято и, если честно, можно встретить все, что угодно — htmlentities и html_entity_decode тому пример, хотя одна кодирует, а вторая декодирует по сути. Такое ощущение, что писали два разных человека. Еще есть магический __toString или jsonSerialize из интерфейса JsonSerializable.

Так что не стесняйтесь и используйте lowerCamelCase.

VolCh 13 июн 2012 в 08:56

underline для переменных, свойств и функций. Для методов как раз lowerCase camel notation.

cypok 13 июн 2012 в 07:25

В каждом языке/фреймворке есть свой стиль именования, о чем вообще опрос?

Как-то так

WinAPI: GetSomeItem
Java: getSomeItem
Ruby: get_some_item
Scala: someItem
...

DmG 13 июн 2012 в 07:33

Т.е вы не стремитесь употреблять один стиль для всех ЯП и фреймворков, а вместо этого подстраиваетесь?

inhibitor 13 июн 2012 в 07:41

По-моему, если выработать общий стиль для всех, а не подстраиваться, это вызовет только путаницу для других участников проектов

cypok 13 июн 2012 в 07:43

В чужой монастырь со своим уставом не ходят.

;)

vaxXxa 13 июн 2012 в 08:42

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

TheHorse 13 июн 2012 в 09:07

В пределах одного проекта, на разных языках, часто используется единая нотификация.

vaxXxa 13 июн 2012 в 09:13

А потом, когда часть кода станет хорошо продуманной и самостоятельной, можно будет зарелизить, как оупенсорс. Можно, но стыдно.
Каждый язык программирование — это отдельная идеология, правила и договоренности. Это же, как писать, к примеру: privet, poka, ia haker, хеллоу, бай, ай эм хакер.

TheHorse 13 июн 2012 в 09:21

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

vaxXxa 13 июн 2012 в 09:23

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

inhibitor 13 июн 2012 в 07:38

Полностью с вами согласен, различие есть и между фреймворками в рамках одного языка, пример для Python: Zope и Django.

EvilShadow 13 июн 2012 в 08:11

Если речь идёт о геттерах, то в руби также будет some_item.

cypok 13 июн 2012 в 08:14

Вы конечно правы!

VolCh 13 июн 2012 в 07:28

some_variable, some_property, some_function, но SomeClass и someMethod

DmG 13 июн 2012 в 07:31

Интересный подход

VolCh 13 июн 2012 в 07:55

Стандартные правила именования PHP.

chEbba 13 июн 2012 в 09:12

Стандартные где? в самом PHP нет стандарта. Есть только стандарты в рамках фреймворков, библиотек, проектов.

VolCh 13 июн 2012 в 09:21

www.php.net/manual/ru/userlandnaming.rules.php и svn.php.net/viewvc/php/php-src/trunk/CODING_STANDARDS?view=co

chEbba 13 июн 2012 в 09:34

Так это стандарт для разработки самого языка на С. Там есть только пара пунктов про юзер-функции

VolCh 13 июн 2012 в 09:55

Не пара слов а побольше, и про методы, и про функции, и про константы, и про переменные.

chEbba 13 июн 2012 в 10:13

Про переменные — это про переменные в С коде

for (i=0; i<100; i++)

Классы и методы похоже относятся к юзер-классам, так как сам PHP на чистом С пишется, насколько я понимаю.
Про константы не нашел.

VolCh 13 июн 2012 в 10:26

Да, с константами я погорячился, откуда-то с другого места взял, а переменные отнёс к PHP по аналогии с функциями.

Volshebnyi 13 июн 2012 в 08:01

В Python абсолютно такой же подход принят за стандарт.

Volshebnyi 13 июн 2012 в 08:46

Вот я соврал, а меня даже плюсанули. Конечно же, для методов правила именования такие же, как для функций.

bildja 13 июн 2012 в 08:46

В python some_method же

OpenMinded 13 июн 2012 в 07:36

Немного странный вопрос. Какой предполагается ответ, если переменные называю с маленькой, а функции с большой буквы (c#)? А вообще, называть нужно не как нравится, а как принято в языке/фреймворке.

StealthDogg 13 июн 2012 в 07:43

C#
методы: GetMyData()
свойства: MyData
private поля: _myData
переменные в теле метода: myData

breeze 13 июн 2012 в 11:13

В принципе тоже использую в таком же стиле переменные — myData, методы — GetMyData(). Ну а теперь ещё буду делать и private поля _myData. Спасибо за идею ;)

helions8 13 июн 2012 в 07:51

Для scheme или clojure использую some-item, get-item.

Agent_Smith 13 июн 2012 в 08:02

Пишу, так как принято в гайдлайнах конкретного языка.

friday 13 июн 2012 в 08:08

Пишу так, как принято в конкретном языке/фреймворке/проекте, но субъективно больше по душе snake_case.

mihaild 13 июн 2012 в 08:14

python: var_name, func_name
C++: varName, func_name

TheHorse 13 июн 2012 в 09:09

У меня уже вот так:
Delphi, JS, С++, C#: varName, FuncName.

AntonShevchuk 13 июн 2012 в 08:38

camelCase for PHP

и да — ссылки на PSR-1 и 2 пусть тут полежат — github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md, github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md

VolCh 13 июн 2012 в 09:07

Переменные, свойства и функции не определяет…

incogn1too 13 июн 2012 в 08:47

На работе:
iGetItem — впереди тип данных
В своих проектах:
get-item

foxmuldercp 13 июн 2012 в 13:52

последнее очень пахнет powershell'ом :)

incogn1too 13 июн 2012 в 15:07

Последнее принято в языках вроде Scheme.

foxmuldercp 13 июн 2012 в 17:19

Возможно. но концепция коммандлетов PSH мне нравится. И видимо, тут msft решила не изобретать велосипед.

red1ynx 13 июн 2012 в 08:58

Как прописано в Style Guide проекта.

KirAmp 13 июн 2012 в 10:27

А у нас по корпоративной этике:

public function get myItem():Item {return myItem;}
private var _myItem:Item

KirAmp 13 июн 2012 в 10:31

return _myItem;

конечно же

Dipp 13 июн 2012 в 11:08

Как-то так. Хотя префикс «m_» самому не нравится, но приходится использовать хоть что-то для отделения переменных класса от локальных переменных функций.

class HelloWorld
{
	int m_variable_long_name;
	int m_result;

public:

	int getVariableLongName() const
	{
		return m_variable_long_name;
	}

	int getResult() const
	{
		return m_result;
	}

	void setVariableLongName(const int variable_long_name)
	{
		m_variable_long_name = variable_long_name;
	};

	void calculateResult()
	{
		int local_variable = 10;
		m_result = m_variable_long_name * local_variable;
	}
};

int02h 13 июн 2012 в 13:02

C#
Методы и свойства: SomeImportantMethod()
Закрытые поля: _someField

Java
Методы и свойства: someImportartMethod()
Закрытые поля: _someField

PHP
Методы и свойства: some_important_method()
Закрытые поля: _someField

serf 13 июн 2012 в 13:12

Могу понять зачем в случае JavaScript, но зачем подчеркивание наименовании приватного поля "_someField" в Java (о других не говорю) если приватность обеспечена самим языком программирования?

int02h 13 июн 2012 в 15:01

Для удобства программирования. Смотришь на название поля и сразу понимаешь откуда оно взялось.

serf 13 июн 2012 в 15:16

В Java это и так видно, конечно если не работать в блокноте. Считаю _ в Java дурным тоном.

int02h 13 июн 2012 в 21:04

Я недавно изучаю Java, но я вот что-то не могу понять как там сходу видно, что поле закрытое в рамках класса? Вы имеете ввиду подстветку в IDE?

serf 13 июн 2012 в 21:24

Да имел ввиду средства IDE. А вообще в Java поля с доступом паблик редкость, не принято. Кстати исходники базовые пакетов Java (JRE) не содержат всяких префиксных подчеркиваний.

int02h 14 июн 2012 в 04:34

По поводу public полей в Java. Я использую Java в основном для Android, а в туториалах от Google написано, что рекомендуется все поля делать открытыми, а не прятать их за методами get и set. Но тут скорее из соображений производительности.

По поводу нижних подчеркиваний. Это стиль у меня пришел из C#, так как у нас на работе политика такая, что код должен быть написан так, чтобы его можно было напечатать на бумаге и читабельность бы не упала. Поэтому полагаться на, например, цветовую подсветку IDE не стоит.

serf 14 июн 2012 в 07:52

Разумеется Android имеет свои приоритеты и да вероятно дело в уменьшении потребления памяти, но открытие всех полей может превратить классы в кашу и позволит легко нарушить задуманную логику работы.

Работаю с Java больше 4 лет, ни в одном рабочем проекте не встречал _ кроме одного недавнего испансокго проекта (на фрилансе), и эти _ зразу режут глаз. Но этот проект вообще отдельный разговор, там все выглядит так как будто систему делают PHP разработчики, помимо этого общего соглашения по стилю нет, технического лидера нет, кодревью нет и тд., то есть понятно откуда там взялось _.

serf 13 июн 2012 в 13:13

Разумность побеждает, в смысле Жависты :)

mjr27 13 июн 2012 в 13:56

pep8 наше всё

So1 14 июн 2012 в 05:27

> наше, питоновское, всё

FTFY

Sombressoul 13 июн 2012 в 18:34

Никогда особо не вчитывался в различные рекомендации по оформлению кода, но для себя вывел примерно следующую схему:
THIS_IS_CONST
thisIsVar
ThisIsFucntion (или f_ThisIsFucntion — если много функционального кода)
CThisIsClass (или c_ThisIsClass)

Shultc 13 июн 2012 в 23:16

… а если всё называть одной буковкой, то таких проблем вообще не возникнет…

So1 14 июн 2012 в 05:14

За многие годы у меня сложились такие правила:

имена
переменных (тип данных — примитив) — items_count = sizeof(items)
инстансов классов — objectsFactory = new ObjectsFactory(«square»)
классов — ObjectBuilder
методов — attachEvent(IEvent $event)
функций — invalidate_cache_key($key)
констант — SEVENTYTWO = 72
интерфейсов — IHttpRequest
абстрактных классов — AHttpResponse

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