Comments 20
В статье вы пишите, что разные стили используются для разных сущностей, а в голосовалке предлагаете голосовать за один для всех... facepalm
Я использую PascalCase для процедур и функций и snake_case для переменных. Если бы я использовал camelCase тогда бы процедуры и переменные состоящие из одного слова невозможно было бы различить (camal процедура и snake переменная).
P. S. 1. "СлипшиесяСловаТрудноЧитать", не соглашусь, 90% времени они используются как токен, подошла бы даже картинка, это не художественный текст, что-то у вас не так с критериями.
" Одноимённые имена файлов" Шта?! Какое отношения имена файлов имеют к языку?
"CSS" Мы о языках программирования или о чём?
какая-то дичь, дальше анализировать не стал.
В голосовалке можно выбрать несколько вариантов.
Как токен воспринимаются лишь частоупотребимые словосочетания сильно отличающиеся от других. В остальных 90% случаев таки приходится читать что там написано.
Имена файлов часто встречаются в коде, а файлы часто именуются в соответствии с содержащимися в них сущностями.
Мы о компьютерных языках.
Время, которое вы потратили на комментарий, лучше бы потратили на чтение - пользы больше было бы.
После дофигаЛет JsReact вчера пришлось с удивлением познакомиться на питоновскую_змею в переменных
Использовал Camel, пока не появился как то проект со множеством сущностей и сложными алгоритмами, где нужно было очень досконально и длинно назвать переменные и методы, иначе они спутывались. В итоге, перешел на Snake, можно сказать вынужденно, т.к. из всех вариантов этот наиболее лёгким для моего восприятия оказался.
Сейчас я ещё из БЭМ фишку взял, как модификатор (в моём варианте "__модификатор"). Когда нужно немного разграничить похожее, типа: person_post__title, person_post__description (это когда нет функционала сложных переменных, или их использование нецелесообразно).
Если правильно понимаю, в современных языках имена функций и переменных чаще всего регистрозависимы? Тогда мой лайфхак с функциями мало кому поможет. Но кому-нибудь может и пригодится, так что
все-таки напишу.
У меня фортран, и он к регистру нечувствителен. Вдобавок моя IDE не показывает определение функции, когда в коде встречается ее вызов, и я не могу перейти к описанию/телу функции одним кликом. А это часто бывает нужно.
В результате я сформировал такой стиль: при вызовах функций в программе я пишу мнемонически наиболее удобочитаемое имя (сначала это был snake_case -стиль, сейчас предпочитаю PascalCase, но старые библиотеки пока еще не все отрефакторил). А в шапке-описании функции (которая у меня всегда стоит перед телом функции) и в теле функции ее имя написано UPPERCASE (если необходимо - с подчеркиванием).
Например
Описание и тело функции:
C.....LOGICAL*4 ALL_SYMBOLS_IN_SET(STRING,SET)....................C
C c*(*) c*(*) C
C Функция ALL_SYMBOLS_IN_SET проверяет, что в строке STRING C
C встречаются ТОЛЬКО символы из набора SET и пробелы C
C.................................................................C
LOGICAL*4 FUNCTION ALL_SYMBOLS_IN_SET(STRING,SET)
.....Использование:
...
if (.not. all_symbols_in_set(search_string,'*<>=+-0123456789.,eEdD'))then
...Когда мне нужно посмотреть описание функции, я выделяю ее имя и делаю глобальный поиск. В окошке с результатами поиска строчки с капслоком сразу же выделяются визуально (т.к. все остальные преимущественно в нижнем регистре). Остается кликнуть по нужной строке и открыть окно с описанием функции.
Мне нраввится вот такой стиль:
music = Rock'n'Roll
f' x = x =)
В статье, все способы имеют только минусы. А потом опа, нате ... из под кровати, змея оптимальный выбор. Почему?
Такое ощущение, что автор писал, держа что то в голове и считает, что об этом всем известно. У меня машинка для чтения мыслей в ремонте. Может как то подробнее про змею развернете?
Там же написано почему.
А мне вот и не приходилось "предпочитать" кейс. Его определяли идиоматика языка( Python<PEP8>, Go<https://go.dev/doc/effective_go#mixed-caps>, Haskell), стиль проекта или культура компании...
Можно вспомнить ещё JSON, который часто используется как формат обмена данными. snake_case в назначениях ключей объектов увеличивает размер передаваемых данных на ровном месте. camelCase компактнее за счёт отсутствия символов подчеркивания.
Когда этот JSON записывается в логи, а логи нужно где-то хранить, то разницу в размере видно невооружённым взглядом, просто по счетам за сторадж.
Если серьезно, используйте тот стиль, который наиболее употребим на конкретной платформе. Даже если он лично вам по каким-то причинам кажется не оптимальным. Вы же не в вакууме пишете - унификация даст гораздо больше преимуществ.
Обычно использую camelCase (для переменных/полей+методов) или PascalCase (для типов). В основном ориентируюсь на стиль Qt, т.к. нередко его использую. Слипшиеся слова как раз не трудно читать, просто не нужно делать их слишком длинными. Трудно - разлипшиеся, имя не воспринимается как единое целое, текст программы "обедняется" за счет использования только одного регистра вместо двух. Но к сожалению в С++ это почему-то стандартный формат для библиотек.
Ну, собственно говоря, причины появления camelCase не потому что это более удачная вещь, по сравнению со snake_case, чем PascalCase. Причины, в общем-то, лежат на поверхности: PascalCase решили немного кастрировать, для языков, где очень много слов начинающихся одинаково (например: get/set), в этом случае, строчные буквы переносят акцент на следующее слово, маскируя "однообразную" часть.
Формат имён в коде