Исходное сообщение
"Выпуск Debian 8.6" Отправлено Аноним, 22-Сен-16 19:37
> Что мне ни о чём не говорит, я спросил. Ваши аргументы были > бы понятны, если бы примеры им соответствовали. Вы же в аргументах > упомянули макросы в нижнем регистре, а в примерах кроме однобуквенных идентификаторов > и числовых констант (с которыми я, кстати, согласен) ничего нет. Вы уверены?  =) > s = new(char, a + 1 + b + strlen(e) + 1); https://github.com/systemd/systemd/blob/09541e49ebd17b41482e... > #define new(t, n) ((t*) malloc_multiply(sizeof(t), (n))) . > "Эпизодически" я сталкиваюсь, по крайней мере, с си и явой. И после > явы, си - это глоток свежего воздуха, отчасти именно потому, что > в яве когда читаешь идентификатор и доходишь до конца, можешь уже > забыть, как он начался. Т.е. вы сталкиваетесь/сравниваете с другой крайностью и считаете одну из них приемлемей, а несогласных с этой самой приемлимостью — "фанатами" другой крайности? Как-то слишком уж радикально. > Но в функции 11 смысловых строк (объявления переменных и проверки аргументов > я не считаю). И мне кажется, что конкретно в данном случае, Похоже, вас не переубедить. Пусть будет так. Хотя ковенции на то и конвенции, чтобы их придерживаться.  Особенно учитывая, что хорошая такая часть кода дублируется в соседних "unit_name_replace_instance" "unit_name_template" – вместо копипасты можно было бы потратить немного времени на нормальные имена переменных. И именно такие вещи обычно признак [эт-самого]-кода. >> или вообще ненужное, как "strlen(e)"? > Хм... вроде оно нужное. Как можно без него обойтись здесь? Для вычисления достаточно длины f. А оная тут вычисляется аж по несколько раз ) unit_name_replace_instance() вызывается к примеру вот тут: https://github.com/systemd/systemd/blob/6afe14ff5b91e6207200... тут https://github.com/systemd/systemd/blob/6afe14ff5b91e6207200... или тут https://github.com/systemd/systemd/blob/6afe14ff5b91e6207200... И каждый раз вызову unit_name_replace_instance предшествует проверка: unit_name_is_valid(... https://github.com/systemd/systemd/blob/master/src/basic/uni... Правда, в самой  "unit_name_replace_instance" она так же присутствует. И в этой проверке заодно вычисляется длина f, позиция е(xtension) и @ (причем и тут, если копнуть, то все это дублируются по нескольку раз. Например в bool unit_instance_is_valid(const char *i) { …     120             * allow them in the prefix! */ 121     122            return in_charset(i, "@" VALID_CHARS); Не, я конечно понимаю, что размеры строк тут скромные и даже десятикратные проверки не будут  особо заметны. Но ... брать Cи, гордо велосипедить свой парсер, работу со строками и т.д, при этом игнорируя  такие "мелочи" ... как-то это уж слишком извращенно.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Что мне ни о чём не говорит, я спросил. Ваши аргументы были >> бы понятны, если бы примеры им соответствовали. Вы же в аргументах >> упомянули макросы в нижнем регистре, а в примерах кроме однобуквенных идентификаторов >> и числовых констант (с которыми я, кстати, согласен) [B]ничего нет[/B]. > Вы уверены? =) >> s = new(char, a + 1 + b + strlen(e) + 1); > https://github.com/systemd/systemd/blob/09541e49ebd17b41482e447dd8194942f39788c0/src/basic/alloc-util.h#L29 >> #define new(t, n) ((t*) malloc_multiply(sizeof(t), (n))) > . >> "Эпизодически" я сталкиваюсь, по крайней мере, с си и явой. И после >> явы, си - это глоток свежего воздуха, отчасти именно потому, что >> в яве когда читаешь идентификатор и доходишь до конца, можешь уже >> забыть, как он начался. > Т.е. вы сталкиваетесь/сравниваете с другой крайностью и считаете одну из них приемлемей, > а несогласных с этой самой приемлимостью — "фанатами" другой крайности? Как-то > слишком уж радикально. >> Но в функции 11 смысловых строк (объявления переменных и проверки аргументов >> я не считаю). И мне кажется, что конкретно в данном случае, > Похоже, вас не переубедить. Пусть будет так. Хотя ковенции на то и > конвенции, чтобы их придерживаться. Особенно учитывая, что хорошая такая часть > кода дублируется в соседних "unit_name_replace_instance" "unit_name_template" – > вместо копипасты можно было бы потратить немного времени на нормальные имена > переменных. > И именно такие вещи обычно признак [эт-самого]-кода. >>> или вообще ненужное, как "strlen(e)"? >> Хм... вроде оно нужное. Как можно без него обойтись здесь? > Для вычисления достаточно длины f. А оная тут вычисляется аж по несколько > раз ) > unit_name_replace_instance() вызывается к примеру вот тут: > https://github.com/systemd/systemd/blob/6afe14ff5b91e62072005dd8eb75315a16989874/src/core/unit.c#L244 > тут > https://github.com/systemd/systemd/blob/6afe14ff5b91e62072005dd8eb75315a16989874/src/core/unit.c#L793 > или тут > https://github.com/systemd/systemd/blob/6afe14ff5b91e62072005dd8eb75315a16989874/src/core/unit.c#L2300 > И каждый раз вызову unit_name_replace_instance предшествует проверка: > unit_name_is_valid(... > https://github.com/systemd/systemd/blob/master/src/basic/unit-name.c#L53 > Правда, в самой "unit_name_replace_instance" она так же присутствует. > И в этой проверке заодно вычисляется длина f, позиция е(xtension) и @ > (причем и тут, если копнуть, то все это дублируются по нескольку > раз. Например в > [/CODE]bool unit_instance_is_valid(const char *i) { > … > 120 * allow > them in the prefix! */ > 121 > 122 return in_charset(i, "@" > VALID_CHARS); > [/CODE] > Не, я конечно понимаю, что размеры строк тут скромные и даже десятикратные > проверки не будут особо заметны. Но ... брать Cи, гордо > велосипедить свой парсер, работу со строками и т.д, при этом игнорируя > такие "мелочи" ... как-то это уж слишком извращенно.
	Введите код, изображенный на картинке: