16 правил качественного программирования от Николая Этюгибосэкю

16 ПРАВИЛ КАЧЕСТВЕННОГО ПРОГРАММИРОВАНИЯ

Вступление.
Настоящая книга является продолжением бывшей моей книги «16 правил хорошего кода». Но теперь внимание уделяется не только качеству кода, но и качеству его исполнения. Иногда быстрое исполнение кода важнее его качества. Все правила являются строго моим текущим мнением (слово «текущим» важно, так как иногда мое мнение меняется) и не претендуют на правду. А некоторые вообще не взяты ни из какой книги или статьи в Интернете, а основаны на моем текущем личном опыте (который является небогатым и не основанным на глубокой теории). Кроме того, есть написанная серым экстра-информация, большей частью являющаяся алгоритмом для одной задачи, а не правилом качественного программирования как такого.

1. Сразу определитесь, что вы ставите целью – чистый код или код, который быстро выполняется. Потому что это – в большинстве случаев антонимы. Хотя есть «антипаттерны», которые нет смысла применять ни в каком случае – они загрязняют код и не ускоряют его, и являются абсолютным злом. Про них – первые несколько правил настоящей книги. Дальше следуют правила, увеличивающие чистоту кода, затем – ускоряющие. Хотя иногда в одном и том же правиле рассматриваются оба аспекта. Также иногда можно встретить и третий класс фрагментов кода – требующие мало памяти. Но следует понимать, что на практике в этом не очень много смысла, так как память компьютеров растет намного более быстрыми темпами, чем тактовая частота процессора. Например, самые мощные современные (на 2020 год) компьютеры, ориентированные на рядового пользователя (не какие-то суперкомпьютеры) имеют более высокую тактовую частоту по сравнению с определенным периодом в прошлом в 3 раза, а больше памяти – в 128 раз. Поэтому отдавайте приоритет быстрым алгоритмам перед требующими мало памяти.

2. Нет смысла программировать высокоуровневые задачи на низкоуровневых языках. Конечно, ядро операционной системы иначе, как на ассемблере, не запрограммировать, но ядро операционной системы – это очень узкоспециализированная задача, нужная крайне редко. А для разработки 99.9% программных продуктов придуманы высокоуровневые языки программирования. Программировать на них значительно проще и быстрее. Кроме того, существуют ультра-высокоуровневые языки программирования. Из таких автор настоящей книги рекомендует C↑ᶜC – самый перспективный язык программирования, выводящий программирование на количественно (в плане функциональности на 100 символов) и качественно новый уровень. То, что высокоуровневые языки намного медленнее – это миф, так как первое – эта разница начинает превышать разницу во времени разработки только, как минимум, на миллиардах безошибочных исполнений какой-либо инструкции (что маловероятно), второе – если разделить скорость выполнения программы на каком-либо языке на скорость среднего процессора в период истории, когда этот язык находится / находился / предположительно будет находиться «на вершине» (а не на частоту одного и того же процессора), то она, скорее всего, окажется выше именно у самых современных языков. (Предупреждение для тех, кто собрался буквально произвести деление и получить что-то в стиле «функциональных единиц программы на такт процессора»: это глупость! Запись выше – не детерминированная статистика, а условная метафора, которая, впрочем, приближенно (но не буквально!) соответствует действительности.) Ну и третье – программирование на высокоуровневых языках намного более безопасно, а на восстановление компьютера и всего, что на нем было, могут пойти просто гигантские временны́е и денежные средства. Поэтому старайтесь пользоваться самыми современными на момент чтения вами этой книги языками программирования, вне зависимости от кажущейся их «медленности».

3. Имена должны в явном виде передавать смысл. Имена в стиле a, ttt, theString, number1 и т. д. этого не делают. Например, в следующем коде нет сложных выражений, пробелы и отступы расставлены грамотно, в нем задействованы только три переменные и две константы, нет никаких запутанных классов или полиморфных методов, и все же с первого взгляда понять, что он делает, практически невозможно.
– Имена из одной буквы имеют смысл только для короткоживущих локальных переменных. В редких случаях – для прочих переменных, если значение этой буквы устоялось в математике или в программировании – например, x, y или n. Для функций и классов – никогда! То же самое касается имен из нескольких одинаковых букв. Префиксы a, an и the могут использоваться, только если конкретно в данной компании существует четкий стандарт, как и когда их использовать, но точно не чтобы создать формальное различие для компилятора. Использовать имена в виде префикса и номера абсолютно лишено смысла. Включать имена типов в состав других имен также плохо: вы можете в соответствии с внезапно возникшими потребностями изменить тип, забыв про имя, и тогда это имя будет нагло врать. При этом избегайте переименований – мозг имеет способность присваивать определенному образу имя в своих недрах, и очень тяжело меняет это имя. В результате вы будете, обращаясь к переименованной сущности, автоматом вводить старое имя, и даже если пальцы уже «привыкнут» к новому, недра мозга одинаково будут, даже если глаза смотрят в упор на новое имя, «выдавать наружу» старое. Я уверен, что эта особенность на самом деле есть не только у меня, а у 99% населения Земли, хотя 90% этого не понимают и искренне думают, что «вот у меня-то» ее точно нет. Поэтому как следует думайте над именем сразу, до того как хоть один раз напишете его.
– Скорость кода не зависит от имен идентификаторов – из одного символа они или из двадцати. В большинстве случаев проверяться будут только первые один-два символа. Поэтому не надейтесь ускорить код идентификаторами из одной буквы. Зато действительно сильно замедляют код множество (десятки-сотни) идентификаторов, начинающихся с нескольких одинаковых букв. Это – апофеоз зла для кода. Кроме того, что это загрязняет код, затрудняя автодополнение, это еще и замедляет его, тратя лишнее время на сравнение имен. Не делайте так никогда!

4. Избегайте «магических чисел». На компьютерном сленге так называются числа, смысл которых неясен из контекста. Конечно, вы понимаете, что это, например, число 123. Но почему именно 123? Почему оно записывается именно в эту переменную? Что с этим числом 123 происходит дальше? А вдруг завтра вам понадобится изменить это число на 456? Придется искать его везде, где оно встречается. А где-то может встретиться ровно такое же число, но с другим смыслом. А вдруг в одном из мест уже сейчас переставлены цифры? Эта ошибка «убивает двух зайцев» с негативной стороны: и ведет программу к неправильному результату, и скрывается от поиска. Для этого в языках программирования придуман такой инструмент, как константы. Дайте константе значимое имя и замените все вхождения этого числа на имя константы один раз. При этом ровно такому же числу с другим смыслом надо дать другую константу, иначе может понадобиться изменить только число под одним значением, а у вас не будет такой возможности. Но используйте константы разумно. Создавать константу для каждого нуля и для каждой единицы лишено смысла. Согласитесь, строка if (pages.Count == 0) читается намного лучше, чем if (pages.Count == THERE_ARE_NO_PAGES). Создавайте константу, только если вам самим неясен смысл какого-либо числа. Что бы ни казалось вашему Чувству Собственной Важности, скорее всего, вы не гений уровня Эйнштейна, а большинство работников вашей фирмы не полные идиоты, поэтому если что-то понятно вам, это, скорее всего, будет понятно и им. Для верности можете написать пять-десять чисел, затем переключиться на хобби, поесть, почитать газеты, поспать и вернуться к этим числам на следующий день – если вы не забыли их смысл, значит, создавать для них константы нет смысла.
– Константы заменяются своим содержимым на этапе компиляции, поэтому не замедляют код. И даже не требуют дополнительной памяти. Поэтому если применение константы оправдано для чистоты кода, оно оправдано во всех случаях.


5. Избегайте функций больше, чем с тремя параметрами, а также параметров с модификатором out. Если вам хочется их сделать, объедините их в класс – в большинстве случаев они объединены общей идеей, и класс будет полезен.

6. Никогда не используйте null в языках, подобных C#. Проверки на null засоряют код, а если, упаси Господи, вы пропустите хоть одну проверку, можете или улететь далеко в космос и затеряться в мировом пространстве, или упасть в пропасть и разбиться. Даже в таких языках, как C↑ᶜC, null может вызвать проблемы. Поэтому всегда думайте головой, прежде чем его использовать! Во всяком случае, пустой конструктор никогда не приведет к тому краху, к которому может привести null. Впрочем, нет ничего плохого в том, чтобы в C↑ᶜC функция возвращала этот тип.

7. Комментарии – это как костыль. Если код нуждается в комментарии, значит, он плохой. Подумайте, что можно улучшить, чтобы код не нуждался в комментарии. Только в редких случаях, когда вы признаете свое бессилие в улучшении кода, и никто не может вам помочь с этим, можете его добавить.

8. Еще хуже закомментированный код. Он впустую занимает место, загнивая и утрачивая смысл с каждым днем. В нем вызываются несуществующие функции. В нем используются переменные, имена которых давно изменились. И с вероятностью 90% он не пригодится никогда! Поэтому, если видите закомментированный код, который не пригодился больше недели, удалите его!

9. Избегайте излишней рекурсии. Хвостовая рекурсия имеет смысл только в функциональном программировании, и я даже не знаю, что это должен быть за язык. Даже в языках, где рекурсия реализуется в виде цикла, как C↑ᶜC, так что переполнение стека невозможно в принципе, для цепочки «вызов функции – определение функции – передача в функцию аргументов – проверка условия остановки – переход на else – вычисление наращивающих результат переменных (как само число n в факториале, но в общем случае это наращивание не обязательно является увеличением какого-то конкретного числа) – запоминание операторов – вызов функции» потребуется намного больше времени и памяти, чем для такой: переход на следующую итерацию цикла – проверка условия окончания цикла – наращивание результата – увеличение счетчика – переход на следующую итерацию цикла. Вы можете наглядно убедиться в том, сколько требуется времени для рекурсии, запустив следующий рекурсивный код:
– И следующий нерекурсивный:
– Этот пример – апофеоз данной проблемы, но даже на обычном суммировании единиц с помощью рекурсии и с помощью цикла разница во времени будет заметной, если этих единиц будет миллион. И то, если вы не рухнете на StackOverflow. Зато в случае, если приходится программировать или рекурсию, или искусственный стек с записью значений в него при каждом наращивании, и если вы программируете на языке, где не может быть StackOverflow – лучше сделать в виде рекурсии, в этом случае она не будет излишней, так как хранение стека на более «верхнем» языке по сравнению с более «нижним» имеет издержки времени и памяти в виде имен переменных, включая поиск переменной по имени, проверки типа каждого элемента стека с нижеследующим приведением к этому типу, разнообразных флагов и индексов и того факта, что «нижний» стек имеет строгую типизацию, а «верхний», даже если и имеет тип, на нижнем уровне, скорее всего, хранится в нетипизированной «куче», где для него требуется больше памяти. Поэтому всегда, когда у вас есть выбор, использовать рекурсию или нет, подключайте голову.

10. Дублирование – это не абсолютное зло. Вызов функции занимает время, поэтому, если вам нужно выполнить какое-либо быстрое действие (быстрее, чем вызов функции, например, базовое арифметическое действие и присваивание) очень и очень много раз (миллиарды), лучше не выносить его в функцию. Кроме того, можно «размотать циклы» – заменить их повторами одной и то же инструкции. Конечно, писать миллиарды одинаковых инструкций – это абсурд, но можно, например, написать десять и таким способом уменьшить количество увеличений счетчика, переходов на следующую итерацию цикла и проверок условия окончания цикла в 10 раз. Но это нельзя делать для операций, которые занимают намного больше времени, чем итерация цикла и вызов функции, так как код станет грязным, а эффект будет нулевой.

Еще как часто! Вы, наверное, не знаете, так как не были в разделе "Бета-тестирование" - первая версия моего компрессора файлов сжимала маленькую веб-страницу (260 КБ или около того) полчаса. А алгоритм RealIDEA шифрует Властелина Колец 20 минут. Это называется, что скорость важна не часто? А в результате оптимизаций компрессор стал сжимать ту же веб-страницу за несколько секунд - в несколько сотен раз быстрее! Конечно, это не оптимизации с дублированием или goto, но яркий пример того, что скорость важна. И можно, конечно, если хватит денег, купить супермощное железо, но у конечных пользователей оно обычное, поэтому у них программа будет работать невыносимо долго. А 98% программного обеспечения ориентировано на конечного пользователя. Так что покупка нового железа - не выход.

В качестве рекомендации - согласен. Но на практике это не всегда осуществимо. У меня, например, был метод, занимавший 158 страниц монитора. В результате я сократил его где-то на 27-28%, но в любом случае до одной страницы сократить его невозможно.

Конечным пользователям неинтересно, какую версию, например, Visual Studio использовал программист.

Это вот что:

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

Спасибо. Только веселить людей не является моей целью.

А те правила слишком объемные. Зато я прочитал целых девять глав Metanit!

Еще как часто! Вы, наверное, не знаете, так как не были в разделе "Бета-тестирование" - первая версия моего компрессора файлов сжимала маленькую веб-страницу (260 КБ или около того) полчаса. А алгоритм RealIDEA шифрует Властелина Колец 20 минут.

Есть подозрение, что ещё как возможно. Это вы просто пока не знаете как.

А если менее детально, то лучше, чтобы книга содержала 2 страницы? И так 8 - это мало для полноценной книги.

В качестве рекомендации - согласен. Но на практике это не всегда осуществимо. У меня, например, был метод, занимавший 158 страниц монитора. В результате я сократил его где-то на 27-28%, но в любом случае до одной страницы сократить его невозможно.

Опять же, что плохого держать форум в курсе разработок? Это же не проплаченная транснациональными корпорациями реклама Coca-Cola или смартфона? Кроме того, только пункт 13 - чистая реклама, а остальные содержат осмысленные правила, по которым хотелось бы прочитать комментарий. Например, про кортежи или про два типа строк.

Опишу, что делает этот метод. А он производит основной синтаксический анализ потока лексем, превращая его в дерево. При этом он симулирует работу стека вызовов с помощью 11 списков с данными в этом стеке, и на каждом шаге перебирает несколько десятков задач, зависящих от конкретных лексем, выбирая одну из них, и на большинстве шагов симулированная рекурсия двигается вниз (добавляя по элементу в каждый из 11 списков) или вверх (удаляя эти элементы). Попробуйте уместить это в один или несколько методов по 25 строк шириной не больше 80 символов каждая, причем так, чтобы не возникло StackOverflow. Если бы вы попробовали, то не писали бы такое.

Если пользователи - программисты, то им ещё как интересно.

Значит вы неправильно оформили метод, не разбили его на составляющие и т.п.
Не должно быть "Методов Бога".

Конечным пользователям неинтересно, какую версию, например, Visual Studio использовал программист.

Считаете, что раз вы смогли только так сделать, значит иначе оно не делается вообще никак?

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

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

Какой у вас опыт в С++, что вы делали реальное на нём, чтобы делать такие категорические заявления?

Если разбить метод на составляющие, будет StackOverflow.

А как, например?

Например, DCASTF - предшественник C↑ᶜC.

Например, DCASTF - предшественник C↑ᶜC.

С какого перепуга?
Или вы это писали для микроконтроллера?

Драйвера писали? Какие у них были проблемы?
"Огромные ИС" писали? Что там были за трудности?

Драйвера не писал, но знаю общее правило, что драйвера должны быть очень быстрыми, а C++ за счет наслоения абстракций этого не позволяет.

Сколько вызовов помещаются в стек (который размером 1 МБ)?

500, 1000, 2000? Конструкция "выражение" имеет 40 вложенных друг в друга разновидностей.

Драйвера не писал, но знаю общее правило, что драйвера должны быть очень быстрыми, а C++ за счет наслоения абстракций этого не позволяет.