Существует длинный скучный технический отчет ISO / IEC 24772: 2013 с длинным скучным названием: «Информационные технологии - Языки программирования - Руководство по предотвращению уязвимостей в языках программирования путем выбора и использования языков». Он преследует две различные цели: во-первых, сократить численность инженеров, утомив их до смерти, и во-вторых, спасти жизни. Он в первую очередь применяется в критически важных областях безопасности, таких как автоматизация атомных электростанций, авиация, автомобилестроение, медицинское оборудование и т. Д. Везде, где цена глупой ошибки больше, чем яростная обратная связь от вашего клиента.
И среди всего скучного, что в нем содержится, есть одно особенно глупое правило:
Используйте последний оператор else или комментарий, объясняющий, почему последний оператор else не нужен во всех операторах if и else if.
Что ж, это очевидно глупо: он говорит вам делать дополнительную работу без всякой пользы. Просто напишите здесь что-то вроде «// this 'if' case doesn’t need 'else'», и это не поможет, не так ли?
Оказывается, было бы. Я соблюдаю это правило с 2013 года, и было много случаев, когда простая мысль о конечном if помогала мне написать лучший алгоритм. Очень легко упустить из виду правильную обработку в худшем случае, когда вы слишком сконцентрированы на том, что делать, когда оператор if соответствует требованиям. Простое отношение к «пустому» else как к подозрительному предотвращает логические ошибки на самой ранней стадии.
Все мы знаем, что это худшие ошибки; и это лучший этап.
Например, в последнее время я работал над устройством чтения сложных форматов изображений. Проще говоря, это выглядит так:
read integer gray values from the file; convert integers read from the file to floating point numbers; if required, make sign compensation; if required, make rescale; if required, invert gray value; ... convert floating points to integers again.
Очевидно, что ни один из этих if не нуждается в else. Но вы знаете, что? Все вместе - делаем. Если ни одно из этих условий не выполняется, нам не нужно выполнять преобразование данных с плавающей запятой. Я провел небольшое исследование и выяснил, что такие случаи вовсе не редкость. Фактически, некоторые из наших самых тяжелых примеров уже представлены в виде файла и не требуют никакой постобработки. Мне нужно было добавить всего пару строк, чтобы учесть это.
read integer gray values from the file; if any processing required, convert integers read from the file to floating point numbers; if required, make sign compensation; if required, make rescale; if required, invert gray value; ... convert floating points to integers again. else // output values are the same as in the file
Само по себе это наименьшее изменение ускоряет работу во многих случаях. И это можно было легко упустить из виду, потому что код и так выглядит прекрасно. Требуется глупое правило, чтобы это выглядело неправильно.
Я не говорю, что такие глупые правила нужно соблюдать невротически. Послушайте, я сам не следовал правилу «иначе» на протяжении большей части «если». Но, учитывая, что для его выполнения нужно так мало усилий и часто приводит к довольно значительным улучшениям, игнорирование таких глупых правил, как это, было бы неразумным поступком.
P. S. Кстати, вот хороший источник общедоступных стандартов и отчетов ISO / IEC, заполненных глупыми правилами вроде этого: http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html.
