LINUX.ORG.RU

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

 , ,


1

1

Сегодня мне попался такой массив структур __versions в коде ядра:

static const struct modversion_info ____versions[]
__used __section("__versions") = {
	{ 0x86e941f6, "module_layout" },
	{ 0x3213f038, "mutex_unlock" },
	{ 0xe1537255, "__list_del_entry_valid" },
	{ 0x4dfa8d4b, "mutex_lock" },
	{ 0x68f31cbd, "__list_add_valid" },
	{ 0x800473f, "__cond_resched" },
	{ 0x542be051, "__x86_indirect_alt_jmp_rax" },
	{ 0x687303f7, "module_put" },
	{ 0x2ea2c95c, "__x86_indirect_thunk_rax" },
	{ 0xbdfb6dbb, "__fentry__" },
	{ 0x9a353ae, "__x86_indirect_alt_call_rax" },
	{ 0x64a62cf6, "try_module_get" },
};

По имени ____versions[]… Грепнула, а там есть и пятерное, и девятерное нижнее подчеркивание. Пруф:

include/linux/rcupdate.h:	typeof(*p) *_________p1 = (typeof(*p) *__force)READ_ONCE(p); \

Зачем вообще используют подобную практику? Неудобно же (да, даже в моно-шрифте), я еще понимаю двойное или тройное, но 9х? Разработчики там сидят и считают каждое подчеркивание, как в Лиспе скобочки? Или может у них есть тулзы для подсчета нижних подчеркиваний? Дискасс


Ответ на: комментарий от Devastator

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

x86-
() автор топика

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).
fluorite ★★★★★
()
Последнее исправление: fluorite (всего исправлений: 1)

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

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

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

camelCase_ptr

menangen ★★★★★
()

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

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

akk ★★★★★
()

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

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

XMs ★★★★★
()
Ответ на: комментарий от XMs

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

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от menangen

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

cocucka ★★★★☆
()
Ответ на: комментарий от fluorite

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

x86-
() автор топика
Ответ на: комментарий от menangen

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

alysnix ★★★
()
Ответ на: комментарий от Oldboy

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

cocucka ★★★★☆
()
Ответ на: комментарий от EXL

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

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

XMs ★★★★★
()
Ответ на: комментарий от EXL

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

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

a1batross ★★★★★
()
Ответ на: комментарий от a1batross

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

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

EXL ★★★★★
()
Ответ на: комментарий от cocucka

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

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

hobbit ★★★★★
()
Ответ на: комментарий от EXL

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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от hobbit

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

cocucka ★★★★☆
()
Ответ на: комментарий от cocucka

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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)

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

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

Usruser
()
Ответ на: комментарий от Devastator

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

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

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

?

korvin_ ★★★★★
()
Ответ на: комментарий от X512

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

HTTPJSONTogRPC

то ли дело lisp…

HTTP/JSON->gRPC
korvin_ ★★★★★
()

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

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

no-such-file ★★★★★
()
Ответ на: комментарий от korvin_

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

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

Devastator
()
Ответ на: комментарий от X512

HttpJsonToGRpc

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

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

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

korvin_ ★★★★★
()
Ответ на: комментарий от sudopacman

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

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

korvin_ ★★★★★
()
Ответ на: комментарий от Devastator

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

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

korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

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

sudopacman ★★★★★
()

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

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

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от Devastator

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от sudopacman

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

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

_foo
korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

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

sudopacman ★★★★★
()
Ответ на: комментарий от korvin_
httpJSON-to-gRPC
httpJSON-RPC
jsonRPConverter
httpJSONgRPC
httpJSON|gRPC
httpJSON:gRPC
httpJSON•gRPC
menangen ★★★★★
()
Последнее исправление: menangen (всего исправлений: 1)
Ответ на: комментарий от EXL

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

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

zerhud
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.