DmG Jun 13 2012 at 11:07

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

1 min

4.3K

Website development*Programming*IT Standards*

Comments 71

DmG Jun 13 2012 at 11:09

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

Zelgadis Jun 13 2012 at 12:09

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

nochnoy Jun 13 2012 at 12:43

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

Zelgadis Jun 13 2012 at 12:58

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

TheShock Jun 13 2012 at 12:49

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

Zelgadis Jun 13 2012 at 12:56

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

QCasper Jun 13 2012 at 13:45

Эгоистично…

Zelgadis Jun 13 2012 at 20:57

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

Paulus Jun 14 2012 at 00:05

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

1101_debian Jun 13 2012 at 11:14

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

IgorMats Jun 13 2012 at 11:18

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

DmG Jun 13 2012 at 11:23

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

MaxRaccoon Jun 13 2012 at 11:31

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

arturich Jun 13 2012 at 12:00

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

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

VolCh Jun 13 2012 at 12:56

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

-2

cypok Jun 13 2012 at 11:25

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

Как-то так

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

+15

DmG Jun 13 2012 at 11:33

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

-3

inhibitor Jun 13 2012 at 11:41

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

cypok Jun 13 2012 at 11:43

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

;)

vaxXxa Jun 13 2012 at 12:42

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

TheHorse Jun 13 2012 at 13:07

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

-1

vaxXxa Jun 13 2012 at 13:13

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

TheHorse Jun 13 2012 at 13:21

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

-1

vaxXxa Jun 13 2012 at 13:23

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

inhibitor Jun 13 2012 at 11:38

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

EvilShadow Jun 13 2012 at 12:11

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

cypok Jun 13 2012 at 12:14

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

VolCh Jun 13 2012 at 11:28

some_variable, some_property, some_function, но SomeClass и someMethod

DmG Jun 13 2012 at 11:31

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

VolCh Jun 13 2012 at 11:55

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

chEbba Jun 13 2012 at 13:12

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

VolCh Jun 13 2012 at 13:21

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

chEbba Jun 13 2012 at 13:34

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

VolCh Jun 13 2012 at 13:55

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

chEbba Jun 13 2012 at 14:13

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

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

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

VolCh Jun 13 2012 at 14:26

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

Volshebnyi Jun 13 2012 at 12:01

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

Volshebnyi Jun 13 2012 at 12:46

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

bildja Jun 13 2012 at 12:46

В python some_method же

OpenMinded Jun 13 2012 at 11:36

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

StealthDogg Jun 13 2012 at 11:43

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

breeze Jun 13 2012 at 15:13

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

helions8 Jun 13 2012 at 11:51

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

Agent_Smith Jun 13 2012 at 12:02

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

friday Jun 13 2012 at 12:08

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

mihaild Jun 13 2012 at 12:14

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

TheHorse Jun 13 2012 at 13:09

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

AntonShevchuk Jun 13 2012 at 12: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 Jun 13 2012 at 13:07

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

incogn1too Jun 13 2012 at 12:47

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

foxmuldercp Jun 13 2012 at 17:52

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

incogn1too Jun 13 2012 at 19:07

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

foxmuldercp Jun 13 2012 at 21:19

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

red1ynx Jun 13 2012 at 12:58

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

KirAmp Jun 13 2012 at 14:27

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

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

KirAmp Jun 13 2012 at 14:31

return _myItem;

конечно же

Dipp Jun 13 2012 at 15: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 Jun 13 2012 at 17:02

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

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

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

serf Jun 13 2012 at 17:12

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

int02h Jun 13 2012 at 19:01

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

serf Jun 13 2012 at 19:16

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

int02h Jun 14 2012 at 01:04

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

serf Jun 14 2012 at 01:24

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

int02h Jun 14 2012 at 08:34

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

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

serf Jun 14 2012 at 11:52

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

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

serf Jun 13 2012 at 17:13

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

-1

mjr27 Jun 13 2012 at 17:56

pep8 наше всё

So1 Jun 14 2012 at 09:27

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

FTFY

Sombressoul Jun 13 2012 at 22:34

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

Shultc Jun 14 2012 at 03:16

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

So1 Jun 14 2012 at 09:14

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

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

Show the best of all time