Четверное нижнее подчеркивание?

Почему нельзя после трёх начать использовать нумерацию? Типа: _, __, ___, _4_, _5_, _6_, etc.?

Удобно, но как-то неортодоксально, это выглядит даже хуже чем в имена переменных добавлять префикс их типа вроде uint32Index, int8Index. Магическое число. Мне больше интересно, зачем вообще нужны такие уровни вложенности, как 4+

https://github.com/torvalds/linux/commit/24ba53017e188e031f9cb8b290286fad52d2af00

rcu: Replace ________p1 and _________p1 with __UNIQUE_ID(rcu)
This commit replaces both ________p1 and _________p1 with __UNIQUE_ID(rcu),
and also adjusts the callers of the affected macros.

__UNIQUE_ID(rcu) will generate unique variable names during compilation,
which eliminates the need of ________p1 and _________p1 (both having 4
occurrences prior to the code change).  This also avoids the variable
name shadowing issue, or at least makes those wishing to cause shadowing
problems work much harder to do so.

The same idea is used for the min/max macros (commit 589a978 and commit
e9092d0).

Мозги у них уже набекрень, вот и чудят, code style там, видимо, с 90-ых

Про camelCase там им скажите

Нижнее подчёркивание смотрится нормик тока в одном экземпляре и в конце слова, чисто как имитация пробела, например:

camelCase_ptr

нижнее подчеркивание

И эс как доллар.

нижнее подчеркивание

Покажи мне верхнее подчёркивание. Ну или среднее

Вот¯же,¯положили! И‾вот‾ещё. Называется надчёркивание, а есть ещё Макрон. Не тот, что звонит постоянно, а тот что https://ru.wikipedia.org/wiki/Макрон_(диакритический_знак)

CamelCaseНиХераНеЧитабеленОсобенноКогдаДлинноеИмя, нужно_использовать_snake_case_тогда_легко_читать_длинные_идентификаторы.

А, то-то же, у меня linux-5.15.32-gentoo-r1. Хорошо, что заменили

читатабельность camelCase зависит от фонта. от отношения размера строчной и заглавной буквы.

У джавистов отдельный котёл в аду!

Я как джавист только рад, что ява работает на 1 миллиарде котлов по всему Аду.

Называется надчёркивание

Ну вот ты и сам подтвердил, что это не верхнее подчёркивание (что это вообще за нонсенс, блджад?), а надчёркивание

У джавистов camelCase, а вот у виндузятников-шарпистов CamelCase.

https://en.wikipedia.org/wiki/Name_mangling)

А у виндузятников-сишников ещё и венгерка сверху.

Но венгерка как генератор уникальных и несущих смысловую нагрузку имён вполне неплоха.

Но венгерка как генератор уникальных и несущих смысловую нагрузку имён вполне неплоха.

Да, не понимаю ненависти некоторых к ней.

CamelCaseНиХераНеЧитабеленОсобенноКогдаДлинноеИмя

Вот только то, что ты привёл — это не Кэмел, которого курить надо, это Паскаль.

Мне CamelCase удобнее читать. «_» используется только в особых случаях. CamelCase ещё место экономит.

Венгерская нотация уродлива и бессмысленна. Обычно иерархия идентификаторов позволяет избегать конфликтов и использовать короткие имена. Глобальных идентификаторов надо по возможности избегать.

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

Ты еще для экономии места переменные называй a,b,c,d и т.д. Тоже мне аргумент.

Мне трудно читать вот_такие_вещи и выглядит оно уродливо. Эти подчёркивания путаются с пробелами, а CamelCase сразу подчёркивает что это целостный идентификатор и отделяет его от остального кода.

Нужно единообразие. Даже ценой безобразия. Удобно то, что привычно. Эффективно то, что предсказуемо.

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

Почему нельзя после трёх начать использовать нумерацию? Типа: _, __, ___, 4, 5, 6, etc.?

А как отличить

_4_abc -- (подчёркивание)4_abc
_4_abc -- (4подчёркивания)abc

?

а CamelCase сразу подчёркивает что это целостный идентификатор и отделяет его от остального кода.

HTTPJSONTogRPC

то ли дело lisp…

HTTP/JSON->gRPC

Зачем вообще используют подобную практику

Чтобы мериться у кого длиннее.

HTTPJSONTogRPC

HttpJsonToGRpc

Возможно «g» не нужно.

А как отличить

Можно договориться, что двойное подчёркивание превращается в одинарное и убирает магию с числами. Т.е. первый вариант __4_abc кастуется в _4_abc, а второй _4_abc в ____abc.

Так нельзя же, чтобы имя переменной начиналось с цифры.

HttpJsonToGRpc

Ужос. Ну ладно Http и Json — так часто делают, но GRpc — это жесть.

Возможно «g» не нужно.

Нужно, gRPC — это конкретный протокол.

Так нельзя же, чтобы имя переменной начиналось с цифры.

Оно и не начинается. В обоих случаях — с подчёркивания.

Можно договориться, что двойное подчёркивание превращается в одинарное и убирает магию с числами. Т.е. первый вариант __4_abc кастуется в _4_abc, а второй _4_abc в ____abc.

Устанешь все эти правила помнить. Да и не наглядны они.

Если принять, что имена переменных не начинаются с цифр и не надо это ограничение компилятора пытаться обходить нижними подчёркиваниями, то и вариант (подчёркивание)4_abc отпадает.

Зачем вообще используют подобную практику?

Такие имена используются либо в автоматически генерируемом коде, либо в макросах. Это такая попытка выбрать имена, которые не будут использоваться в остальном коде. Неудобство использования это как раз фича.

Разработчики там сидят и считают каждое подчеркивание, как в Лиспе скобочки?

Эти имена спрятаны внутри макросов, и не предполагаются к прямому использованию. Наоборот, предполагается, что тебе как разработчику никогда не придёт в голову выбирать такие имена переменных в своём коде, и поэтому не возникнет проблем.

Почему нельзя после трёх начать использовать нумерацию?

Можно что угодно. Правила именования из стандарта Си в ядре не указ. Но зачем? Какую проблему решит это дополнительное соглашение об именовании?

Если принять, что имена переменных не начинаются с цифр и не надо это ограничение компилятора пытаться обходить нижними подчёркиваниями

При чём тут какое-то ограничение? Символ подчёркивания — валидный первый символ идентификатора. Никак не связан с цифрами.

_foo

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

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

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