Другие языки программирования и технологии

Господа програмисты, пишите ли вы после оператора выбора if альтернативу else и пустой оператор{}?

1) Сначала расскажу небольшую историю:
Програмист ложится спать и на тумбочку возле кровати ставит два стакана. Один с водой, другой пустой.
Его спрашивают "Зачем?"
"Если захочу пить, выпью воду."
"А пустой зачем?"
"А если не захочу."
Попробуйте рассказать непрограмистам...

2) Стандарт надёжного програмирования MISRA рекомендует писать так:

if(/*захочу пить */)
{
/* выпью воду */
}
else
{
}

P.S. А кто нибудь пишет так?
if(/*не захочу пить */)
{
}
else
{
/* выпью воду */
}
М.
Миха ...
38 256
а чё какая-то там мисра указывает как кодить?

есть другой рифмлоплёт
сонар
он такую хрень как мисра впаривает не пропустил бы
Руслан Сайфутдинов
Руслан Сайфутдинов
53 298
Лучший ответ
Миха ... А если вашу программу необходимо сертифицировать а без неё бумажку не дадут.
Разумеется, не пишу. Это совершенно бессмысленное загромождение кода. Более того, ни один язык программирования, изначально предназначенный для написания надёжных систем, не включает в себя требования обязательного else. А вот фигурные скобки ставлю всегда - т. к. это безусловно влияет на надёжность.

Что касается принадлежности конкретного else конкретному if (о чём сказал None), то отступы куда лучше показывают структуру кода, а любая нормальная IDE умеет автоформат.

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

Создатели языка С сознательно выбросили на помойку надёжность - ради достижения максимальной производительности. И MISRA C - заведомо провальная попытка сформулировать правила, позволяющие хоть как-то увеличить надёжность кода, написанного на предельно ненадёжном языке. На википедии в статье "MISRA C" есть очень интересная фраза: "Несколько исследований ставят под вопрос эффективность правил MISRA. В частности, выявлялась негативная корреляция между нарушениями правил MISRA и наблюдаемыми сбоями программ.", которая означает, что НАРУШЕНИЕ этих правил УЛУЧШАЕТ надёжность кода.
Миха ... Проблема в том, что есть бюрократы, которые требуют.
Пишу
if(/*захочу пить */)/* выпью воду */;

Всё! На мой взгляд, куда легче читается.
На работе почти всегда пишу, потому что как в основном блоке так и в else кроме основной логики еще пишутся выводы в лог файл. И если if не сработал - из логов должно быть понятно почему. Иначе не будет никакой возможности разобраться что произошло
1. Пустой else не пишу.
2. Условие стараюсь писать так, чтобы вероятность "истины" была выше.
Берик Катуов
Берик Катуов
25 516
Возможно, это рекомендация, чтобы избежать ошибки в принадлежности блока else к тому или иному if, например, в цепочке вложенных if-else-if. Или же рекомендация для того, чтобы человеку, читающему код, было легче его воспринимать в той же ситуации с вложенными if. Такие участки компилятор оптимизирует, поэтому издержек быть не должно.
Uladzimir Smolich
Uladzimir Smolich
3 568