Всем добрый. Сразу говорю, что тема задумывается не для холиварных войн, а для пользы дела.

Я обычно как-то не заморачиваюсь по поводу того, в каком стиле именовать объекты, как партия сказала, так и делаем, им виднее. Да, иногда бывают неприятности, но молча матернулся и поехал дальше. Сейчас созревает необходимость в небольшом очередном велосипеде для проекта, некий простой DSL, и вот задумался над этим вопросом, хотелось бы для себя и своей команды всё-таки поменьше матов.

Хотелось бы узнать мнение тех, кого, например, достали имена через подчёркивания, популярные в C/C++, кто не любит ВерблюдоКараванов, как египетских бедуинов. Кто-то может работает с языками, где есть красивые решения, а кто-то может ночами не спит из-за своей мечты, и т.д.

Я попытаюсь выделить некоторые типовые подходы, интересные мне, и на их основе спросить что-то более конкретное. Но если кто-то поделится чем-то и за их рамками, то буду лишь только весьма признателен. И так.

1. Лисп-имена: такие-вот-идентификаторы

Я не лисповод, но такие идентификаторы мне очень симпатичны, они реально удобно позволяют задавать длинные имена, когда это необходимо. Не говорим сейчас о функциональности лиспа и о его "скобочности", но в целом, код лиспа смотрится гармонично, стройно, все в едином стиле. Для меня иногда есть "разочарования" в таких символах в начале имен как " ` ~ : ^ # @ % " и пр., но в этой среде это приемлемо и удобно (вот в каком-нибудь SQL они не к месту, если ? и : для имен параметров это терпимо и даже хорошо, но @ для переменных — имхо, перебор).
Причём эти идентификаторы удобны не только в коде, но и в каких-нибудь списках данных, например, при автокомплите из минибуфера/ком.строки в эмаксе.
Доводилось видеть такие идентификаторы в алгоритмических языках с типовым синтаксисом. Там они не удобны, особенно если требуется выделять операцию минус, как минимум через пробелы. Но хорошо такие идентификаторы смотрятся в CSS, например.

Вопрос, собственно лисперам. Удобны ли такие записи, и не возникает ли желание, например, заменить дефис на подчёркивание? (имхо, скорее нет, как минимум дефис набрать проще, чем подчёркивание).


2. Идентификаторы через подчёркивание: under_score

Популярны в С/С++, сразу вопросы:

— есть ли к ним какая-то неприязнь, почему?
— удобно ли, когда все идентификаторы в таком стиле, всё в нижнем регистре (за редким исключением), включая и имена типов?
— хотелось бы обязательно выделять типы через большую заглавную букву, особенно в декларации функции внутри списка параметров (т.е. рядом с именами параметров) ?

И такой вопрос. Как лучше именовать объекты с большой буквы, особенно которые рядом с under_score?
В С/С++ прижилось то, что константы/enum-ы — всё в верхнем регистре, этот момент опускаем. Также нет проблем с короткими однокоренными словами, но как лучше быть, скажем, с длинным именем типа:

— Very_Long_Type (в принципе, не редкость)
— VERY_LONG_TYPE (т.е. как константы, сейчас игнорируем С/С++, речь не о них конкретно)
— VeryLongType (т.е. рядом с under_score будет и CamelCase, тоже не редкость)

Теоретически, есть возможность указывать как-то так: [Very Long Type]
но в языках типа С++ такого не простят.

В качестве примера хорошего кода, где часто используется under_score, вспоминается Lua, где нет имен типов, выделяют с заглавной буквы некоторые спец-имена, например каких-то констант, которые часто короткие — красота, фактически почти что лисп. Некоторым "end" не нравится — можно глянуть на MoonScript (некий CoffeeScript для Lua), там и end-а нет (но есть другие недостатки).


3. Верблюжьи караваны: CamelCase

Я не в курсе про истинные исторические причины, но, имхо, в java решили сделать всё в едином стиле, якобы избавиться от смеси under_score и CamelCase. В нет-е, и остальным, это досталось "по наследству". В принципе, жабе с дотнетом, и С++ можно и нужно простить всё, они и так измучены и венгерской нотацией, и префиксами "m_" с "C..." и т.д. и т.п. (как по мне, это ересь от лукавого, но к сожалению вынужденные меры, иногда оправданные). Но от Хаскеля я CamelCase не ожидал, даже был удивлён, там рефлекторно ожидал under_score (как основной принцип, за under_score там по голове не бьют, конечно).

Лично мне, CamelCase — не очень. Он слабо различается, на фоне under_score, вот когда разные слова: "Camel Case", это приятно. Также слабо различаются слова, которые отличаются по заглавной букве (большая/маленькая) и это отличие важно, причём как при похожих словах: "CamelCase camelCase", так и в группе разных слов (кстати, сами слова в группе лучше различаются, когда всё в одном регистре).

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

Вопрос, скорее, к любителям Хаскеля. Нравится ли CamelCase в языке, может есть гипотетические идеи что-то изменить ?


4. Принцип Эрланга: переменные с Большой, остальное всё с маленькой.

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

Вопрос к Эрланговодам: нет ли желания сделать наоборот — функции и переменные с маленькой, а атомы с большой?


5. Игнорируем регистр: case insensitive

В языках вида C/C++/Java/C# чувствительность к регистру позволяет и часто подталкивает писать идентификаторы вида: Buffer buffer (имхо, масло масленое, как по мне, но это гордость этих языков, в какой-то степени). В Delphi/Pascal вынуждают как стандарт писать 'T' в начале имен типов. Язык обязательно этого не требует, но весьма рекомендуется, чтобы было меньше проблем. С натяжкой, в какой-то мере, можно сказать, что это недостаток. Но в SQL, например, не могу и вспомнить, что там неприятного по этому поводу. Можно сказать, что есть нехорошие послабления для каких-то корпоративных стандартов, но с другой, вроде больше гибкости и свободы, а также языки более устойчивы к опискам.

Короче говоря, видит ли кто-то фатальный недостаток, если язык нечувствительный к регистру ?


6. Умный, гибкий регистр: soft case (обзовём его так, неважно)

Это когда в языке такие идентификаторы одно и тоже (есть и такие):

— get_url, Get_Url, getUrl, GetUrl, getURL и т.д.

С одной стороны — гибкость, каждый пишет как ему нравится, меньше описок, но с другой — полный беспредел, бюрократы по стандартам останутся без работы. Также есть технические проблемы, например, для поиска нужно будет часто дёргать регулярки, возможно необходимы частые переформатирования исходников, особенно чужих.

Кто-то работал с таким языком на практике ?


7. Принцип выделения через Большую букву публичных объектов.

В ряде популярных языков весьма рекомендуют именовать публичные элементы с большой буквы. Но кроме рекомендаций, есть языки, где это заложено на уровне синтаксиса, как например Go. В нём, конечно, этот принцип гармоничен, нет никаких лишних слов "public, private, protected и прочая ересь", но с другой, если меняется "публичность" у элемента — занимайся рефакторингом, ибо как "промышленный" язык он, естественно, строг к регистру (теоретически, есть возможность сделать послабление к регистру, и учитывать публичность только при объявлении элемента). Кроме того, есть некое смешивание идентификаторов: и типы и функции могут писаться одинаково (хотя нельзя сказать, что это недостаток).

Кто-то Go на практике погонял уже ?


И ещё один вопрос, тесно связанный с последним пунктом, опять же любителям Хаскеля. Мне очень симпатична его модель публичности, когда все экспортируемые элементы указываются в заголовке модуля, со всей документацией. Но всё-таки, не возникает ли желания иметь какое-нибудь слово "public" рядом с объявлением/реализацией элемента внутри модуля, т.е. как бы на месте видеть, что элемент публичен? (пока можно не говорить о том, что это не впишется в стройность языка)


Как-то так. Сорри, что несколько громоздко. Заранее всем спасибо.