и о культистах

[ex0_planet]

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

И действительно, как вспомню сколько было потрачено моего времени на борьбу с запретом goto, с запретом множественных точек выхода, с венгерской нотацией (в майкрософтовском смысле), с обязательной проверкой всех аргументов в каждой функции… аж вздрогну. Сколько этих безумных, дебильных карго-культов накопилось в индустрии… и никто не считает нужным не то что бороться с ними, а даже и просто понять контекст в котором эти запреты были актуальны, а так… что-то где-то слышали, и при этом уже рвутся в бой писать правила игры. У них что, в детстве в песочнице всё время совочек отбирали, или что?

Comments

[alex-avr2.livejournal.com]

Да здравствует MISRA!

[ex0_planet]

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

[alex-avr2.livejournal.com]

П.С. CamelCase?

[ex0_planet]

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

[alex-avr2.livejournal.com]

А как венгерская нотация существенно влияет на размер кода?

[ex0_planet]

технически да, не влияет. но вот выбешивает также, как удвоение размера :-)

[alex-avr2.livejournal.com]

Ааа, ну вот видишь, тут каждому свое :)
Меня например CamelCase выбешивает как утроение :))
Впрочем и венгерская нотация и еще много-много чего.
Мне, как человеку пишущему софт в 99% случаев под микроконтроллеры, да еще и без использования всяких там либ и HAL - вообще на "обычные, комповые" программы смотреть больно :)

[ex0_planet]

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

[alex-avr2.livejournal.com]

Я если честно не сильно в теме про это :)

[ex0_planet]

да прямо отсюда можно начать
http://stackoverflow.com/questions/111933/why-shouldnt-i-use-hungarian-notation

Гуглится легко в общем; скорее всего имела место неоднозначность перевода type|purpose|kind. Пугает то, с какой легкостью бессмысленное, в общем, действие подхватили ширнармассы.

[nicka-startcev.livejournal.com]

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

плюс, венгерская нотация обычно ассоциируется с вин32апи, где вместо понятного

"FILE *f = fopen(path,"rw")" 

приходится писать что-то типа

HANDLE hMyHandle1 = CreateFile( lpszFileName, FILE_MODE_READ | FILE_MODE_WRITE, NULL_MODE1, FILE_SHARE_NONE, NULL_MODE2, NULL_TEMPLATE1, NULL_FOO, NULL_BAR );

что заметно менее читабельно.

[poor-sysadm.livejournal.com]

чтобы обойтись без goto нужны break с меткой из блока, а не только из цикла, а этого нет почти ни в одном языке.
проверка аргументов может быть полезна для того, чтобы нормально журналировать ошибки а не производить segfault на каждый чих.
(или заёбывающий жабий null pointer reference во всяких говнопродуктах).

[ex0_planet]

тока надо учитывать два момента: так отлавливаются только очень простые ошибки; второе, реагировать-то на это как?

[poor-sysadm.livejournal.com]

само по себе оно ошибок не выявит, но может помочь избежать расползания ошибки по функциям (косяк в одной, а вылетело в другой). Неужели лучше сидеть и в дебаггере проверять правильность аргументов вручную? :)
Ну а размер кода - препроцессор никто не отменял :)
Как обрабатывать - должно быть единое соглашение, возвращать E_INVALID_ARG, поднимать исключение, делать abort() - надо придерживаться единого стандарта, принятого для данного проекта.

Я на эту тему у себя писал, код проверок в грамотном коде на C занимает БОЛЬШУЮ часть объёма. Если write с неправильным файловым дескриптором вызывает kernel panic - это моветон :)
А любая пропущенная условно ненужная проверка рано или поздно окажется в security bulletin. Ибо если те функции, которые есть сейчас, всегда передают правильные аргументы, рано или поздно появится новая, которая в какой-то ситуации передаст неправильные.

[ex0_planet]

Да пожалуйста, можно хоть по три кода завести: E_INVALID_ARG2, E_INVALID_ARG3,... дальше-то что? Вот какая должна быть реакция кода, который получает EINVAL там, где он его не ожидал, передать дальше наверх/поднять исключение? Ну поймали мы его где-то на уровне UI, показали табличку "усё пропало", всем от этого хорошо станет?

Поймите же наконец вы, поборники обсессивно-компульсивного стиля кодирования, что любая, абсолютно любая ошибка означает, что запорот некоторый кусок работы, и чтобы дальше осмысленно продолжать, надо восстановиться. И закладывается такая возможность на этапе системного проектирования, причём в каждом конкретном случае и на каждом уровне абстракции методы восстановления будут свои (где-то можно и процесс уронить, перезапустив джоб потом в супервайзере). Иногда можно и проверку аргументов сделать, чаще всего это осмыслено на межмодульных интерфейсах, но и она не решает всех проблем. А пихать проверку всех подряд аргументов в coding standard и на этом успокаиваться — долбоебизм, за который надо ссаными тряпками гнать из профессии. Пример:

char *join(char **array)
{
   size_t total = getsize(array)
   char * buf = malloc(total);
   ...
   char * r = buf;
   for(...)
   {
      buf = _concat(buf, array[..]);
   }
   ...
   return r;
}

вот кому и чем поможет, если _concat в приведенном примере будет проверять свои аргументы (при условии что она является внутренней для данного модуля)?

> Я на эту тему у себя писал
ссылку?

[poor-sysadm.livejournal.com]

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

[ex0_planet]

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

[poor-sysadm.livejournal.com]

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