Языки в которых принят snake_case

Валерианочка тебя спасет. CamelCase это рациональный выбор.

ну просил же, не важно кто там более рациональный. Об этом можно спорить бесконечно. Меня интересуют языки, может кто знает.

tcl/tk

> Меня лично несколько бесит {c,C}amelCase

Вы не поверите, но меня и еще многих людей также коробит от snake_case :)

> Итак вопрос: кто знает язык (распространенный/акутальный), где _принято_ писать в snake_case?

Надеюсь это не основной ваш критерий выбора языка? :) Навскидку в ocaml так пишут, по крайней мере стандартная библиотека использует такой стиль. Сам я лично считаю приемлемым lisp-style или CamelCase.

мимо. В tcl принят CamelCase.

Берем пример отсюда: http://wiki.tcl.tk/460

proc transformFile {from to inputFile outputFile} {

> Надеюсь это не основной ваш критерий выбора языка? :)

Основной и единственный. Я не выбираю язык под задачу, скорее язык ради языка. Чтоб глазу было приятно. Мне всем нравится "С", но хотелось бы к нему найти ему пару -- динамический/скриптовый язык. До сих пор я пользовался bash/unix tools для прототипов, потом переписывал на Си. Вот подискиваю что-то среднее между bash и C, но и чтобы меня на изнанку не выворачивало. Пока думаю в сторону lisp'a.

Меня даже несколько пугает, что на сегодняшний день CamelCase везде. А snake_case найти что-то трудно.

p.s. За ocaml спасибо, вроде оно. Но явно не скриптовый, и боюсь не слишком актуальный. И слишком многословный "object .. end;;"

От шифта мизинец побаливает иногда.

OCaml, но там это диктуется синтаксисом.

> явно не скриптовый

 ~ % cat 1.ml 
#!/usr/bin/ocamlrun ocaml

print_string "ORLY?\n"
 ~ % ./1.ml  
ORLY?

> боюсь не слишком актуальный

Срочно, немедленно телеграфируйте об этом в MS REsearch!11 Тамошние мужики не знают.

> И слишком многословный "object .. end;;"

Ну на это я даже отвечать не буду, слишком толсто, извините.

a3, извиняюсь если обидел. Я ничего против OCaml'a не имею.

> #!/usr/bin/ocamlrun ocaml

C "С" тоже так можно, например c TinyCC: #!/usr/bin/tcc -run

"C" вдруг стал "скриптовым"? Дело в том, что любой язык можно интерпретировать на лету (кстати я думаю TinyCC НЕ интерпретирует), но скриптовым он от этого не станет -- в самом языке нет нужного... синтаксического cахара что-ли (исключаем добавление кучи библиотек или прогон файла через m4).

> Срочно, немедленно телеграфируйте об этом в MS REsearch!11 Тамошние мужики не знают.

Хе-хе. MS таки идут своей дорогой, но в любом случае если его использует MS R, то круто.

> Ну на это я даже отвечать не буду, слишком толсто, извините.

Многословность понятие субъективное, опять же -- это дело моего "вкуса". Я не троллю, просто говорю как вижу сам.

> a3, извиняюсь если обидел. Я ничего против OCaml'a не имею.

Ну что вы право, нисколько.

> в самом языке нет нужного... синтаксического cахара

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

Сахара тебе, а яйца вареньем не помазать, че? Только мудак выбирает языки по синтаксису.

Ладно не ссы пиши на петуни, как раз по тебе.

> По такому критерию, кроме sh и нет скриптовых языков.

Есть-есть. Пример тому Perl. Язык настолько гибкий, что из него можно делать шелл. Многие его не любят именно за то, что там много сахара, но в скриптах это нужно.

И Perl всем хорош, но и там CamelCase!

Та гибкий токо чутка мертвый

>snake_case

может python?

основатели tcl/tk обходились "snake_case"
и вообще на этом не сильно все и зацикливались
можно по разному - все от стиля автора программ.

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

Вероятно, CamelCase так быстро инфицирует умы тем, что оставляет чёткую возможность для отличия идентификатора типа ('String') от идентификатора переменной ('string'). Потому, вероятно, тебе стоит искать среди не-ООП языков.

PS. пишу в сях на plain_old_case, на яве - в рекомендованный в ней smallCamelCase/TrueCamelCase/UPPER_CASE; трудностей не ощущаю, считаю положение дел естественным.

> может python?

Нет, там тоже есть CamelCase. :-/

> трудностей не ощущаю, считаю положение дел естественным.

Я пытаюсь себя заставить, но пока не выходит...

> Вероятно, CamelCase так быстро инфицирует умы тем, что оставляет чёткую возможность для отличия идентификатора типа ('String') от идентификатора переменной ('string').

Излюбленный довод... А что, в C++ или в Java, например, без "цветовой дифференциации штанов" непонятно, где тип, а где переменная?

Нет, не понятно. В куске "A = B();" B может быть как типом, так и переменной. Заметь, я говорю о законченном выражении.

Erlang

PHP :)

+1)))

>+1)))

Кстати, смех смехом, а в своём фреймворке я использую snake_case для разделения элементов пути к файлу с классом. Т.е.:
при $x = new my_super_puper_object($id);
будет грузиться автоматом из
<some_dirs_array>/classes/my/super/puper/object.php

Сперва я по Java-привычке сделал использование именно CamelCase, но потом забил, т.к. оно менее наглядно. Да и недолюбливаю я CamelCase за неоднозначности с сокращениями/аббревиатурами :)

TCPIPSocket или TcpipSocket? И то, и другое - ужасно :)

basic

Какая тебе разница если ты сам писать будешь ?

Я привык public-методы и переменные писать в CamelCase, private начинать с underscore и писать в snake_case, названия классов в CamelCase. За их положением в ФС следит package manager :)

Т.е.

class MyClass extends CommonClass {
public $classVar;
private $_class_var;

public function getClassVar($varName){
}

private function _get_types_from_registry(){
}
}


> TCPIPSocket или TcpipSocket?

TcpIpSocket :)

>TcpIpSocket :)

Всё равно ужасно :) Опять же - USAFlag или UsaFlag? Как ни крути, но CamelCase неработоспособен с аббревиатурами.

>Нет, там тоже есть CamelCase. :-/

в именах классов. А во всех остальных местах, вроде как, snake_case.

>Нет, там тоже есть CamelCase. :-/

python+django?

> CamelCase неработоспособен с аббревиатурами.
Не то чтоб неработоспособен. Но он обходится с ними жестко. В любом случае - требуется спец. соглашение о них.

ЗЫ Но я не вижу проблемы с TcpIpSocket, если честно

> TCPIPSocket или TcpipSocket? И то, и другое - ужасно :)

А как ты напишешь это в underscore_style?

t_c_p_i_p_socket?
tcpip_socket?
tcp_ip_socket?

Думаю, понятно, что эти варианты отображаются на CamelCase взаимно однозначно.

Я предпочитаю писать TcpipSocket, т.к. для меня tcpip - это одно слово. Верблюд - животное в нашем зверинце новое и необычное, но вполне корректное и жизнеспособное.

>Не то чтоб неработоспособен. Но он обходится с ними жестко.

Ну, я выразился просто жёстко. Ибо натерпелся :) Неудобно, в общем.

>ЗЫ Но я не вижу проблемы с TcpIpSocket, если честно

Просто пример первый попавшийся и не такой жестокий.

Из практики. Хотя тоже не самый удачный. Есть, например, система классов L2. В ней есть объекты PC (Playable Character). Там, скажем, класс Instance. Так имя класса становится L2PcInstance. Уже плохо :)

...

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

RequestExMPCCShowPartyMembersInfo
ExMPCCShowPartyMemberInfo
AdminBBSManager
SSQInfo
RRDTools
BanIPList

и т.д. и т.п. :)

Или приходится аббревиатуры извращать, или названия в нечитаемом виде использовать :)

>А как ты напишешь это в underscore_style?

А там всё строго. Всё строчными буквами :)

tcpip_socket

> TCPIPSocket или TcpipSocket?

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

>За их положением в ФС следит package manager :)

Но есть тонкость. Классы, типа GMViewWarehouseWithdrawList имеют слишком длинные имена файлов :) Работать не удобно, особенно на удалённых машинах по SSH.

У меня же это будет

gm/view/warehouse/withdraw/list.php

:)

Заодно получается, во-первых, группировка файлов по общему контексту, во-вторых, разгрузка каталогов - уже не лепится по нескольку сот файлов в один каталог.

...

Нет, понятно, что с namespaces можно аналогично сделать - но неудобно.

...

Так что, если когда-то за JBForth2 возьмусь, там будет аналогичная система класслоадинга :) Ну, разве что, придётся отдать дань традиции и сделать её тоже с camelCase.

> L2PcInstance. Уже плохо :)
Уныленько, но знающему контекст по идее должно быть понятно. Хотя я б, конечно, подумал бы про L2PCharInstance или что-то в этом духе..

Остальные примеры - тоже можно заверблюдить. BanIpList - ничуть не хуже, чем приведенный вариант. В сущности, подобные имена рассчитаны на то, что человек знаком с используемыми аббревиатурами.

>Следовательно, аббревиатуру надо полностью писать большими буквами. Очевидно же.

Для меня - очевидно. (Но некрасиво). Для многих других, в т.ч. в этом топике (и в моих проектах) - нет :)

Какая у нас каша с именами из-за этого была. Где-то IPList, где-то IpList, где-то PCData, где-то PcData, где-то IDFactory, где-то IdFactory... Вот эта неоднозначность (в смешанной команде ;)) и бесит.

В то время, как с ip_list, pc_data, id_factory - никаких однозначностей и сплошное единообразие. Можно даже при желании класслоадер заставить ругаться на прописные буквы :)

>Уныленько, но знающему контекст по идее должно быть понятно.

Понятно. Но когда у тебя L2PcInstance пишется так, а PCData - так, то уже начинает колбасить :) Ну да, рефакторинг с переименованием - это 5 минут (если имя класса, правда, не фигурирует в записях в БД и не грузятся рефлексией, как у нас, но это тоже лечится). Но потом приходит кто-то ещё и новый класс лепит опять по-своему...

>BanIpList - ничуть не хуже

Но Ip - это не слово :) Даже американцы не пишут же свою страну Usa.

> Но есть тонкость. Классы, типа GMViewWarehouseWithdrawList имеют слишком длинные имена файлов :) Работать не удобно, особенно на удалённых машинах по SSH.

Эм, я делаю vim GM<Tab> и все нормально :) Все файлы классов собраны в пакеты, которые лежат строго на своих местах в нормальной (для меня) иерархии и имеют названия, отражающие название модуля или библиотеки, а не класса. А вот такая

> gm/view/warehouse/withdraw/list.php

вложенность уже overhead, по-моему.

Допилю систему, выложу в OpenSource :)

>Эм, я делаю vim GM<Tab> и все нормально :)

А если там выпадет 500 классов? :) А если грузится класс через рефлексию? :)

Вот от таких "если" меня и защищает система пакетов и package manager. А причем тут рефлексия, если ты правишь файл?

> В куске "A = B();" B может быть как типом, так и переменной.

Ага, а ещё функцией. В любом случае скобочки говорят о выполнении действия, в результате которого получается объект. К чему я клоню: в этом примере без контекста тип от переменной или от функции действительно не отличишь, но смысл выражения всё равно ясен. У меня не возникало проблем с чтением исходников, написанных только в snake_case или только в CamelCase (брр!). Больше проблем от кривых отступов...

>А причем тут рефлексия, если ты правишь файл?

Потому что ты можешь править CSV-файл с именами классов в одном из полей :)

Ну и что? :) Мои классы имеют достаточно короткие имена.. А вот в чем разница, править имя very_long_class_name_who_loaded_by_reflection_api или veryLongClassNameWhoLoadedByReflectionAPI?

Ну да, в данном контексте разницы нет :)

> TCPIPSocket или TcpipSocket?

TcpipSocket, но IPAddress

Если аббревиатура состоит из трех или более символов -- регистр меняют на нижний, если из одной или двух - записывают в верхнем.

>TcpipSocket

Почему не TcpIPSocket тогда?

>Если аббревиатура состоит из трех или более символов -- регистр меняют на нижний

Т.е. Usa, Svn, Udp? :)

Это ужасно.

В известном смысле, соглашение об использовании аббревиатур может вводиться произвольно. Главное, чтоб оно было и всеми соблюдалось. Хотя для каждого соглашения можно найти идентификатор с аббревиатурами, который будет неэстетичным..