Правила хорошего программирования. Правила программирования и автоматизации

Все мы люди и нам свойственно ошибаться. И даже компьютеры ошибаются, если программа, за счет которой они работают, была написана с ошибкой. Чтобы помочь Вам избежать некоторых ошибок при написании программ на любом языке программирования я расскажу о некоторых правилах используемых при написании программ и о методах программирования. Соблюдение ниже описанных методов поможет не только избежать некоторых ошибок, но также предупредит их появление и упростит отладку Вашей программы. Все ниже приведенные примеры и код программ написаны на языке Visual Basic 6.0. Вы можете использовать материал данной статьи и для других языков программирования. Статья не привязывает Вас к какому-либо конкретному языку и является универсальной.

Метод проектирования программных средств

Для решения задач программирования используется "Метод проектирования программных средств". Этот метод состоит из нескольких этапов:

1. Определение условий задачи.
2. Анализ задачи.
3. Создание алгоритма решения задачи.
4. Реализация алгоритма.
5. Тестирование и отладка готовой программы.
6. Поддержка и обновление готовой программы.

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

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

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

Наверное, всем кто изучал программирование или информатику в учебных заведениях рассказывали, как нужно чертить блок-схемы. И наверняка большинство не любит их чертить. Ваш покорный слуга также относится к их числу. Но не стоит думать, что блок-схемы абсолютно бесполезны в программировании. Лично я никогда не черчу блок-схемы при разработке программ, но я умею хорошо это делать. И настоятельно советую Вам, научится чертить их лучше всех. Если Вы не научитесь самостоятельно и правильно чертить блок-схемы, Вы не сможете осознать суть того, как работает программа! Именно блок-схема позволяет наглядно и понятно (схематически) показать, как пошагово (построчно) выполняется программа. Ведь блок-схема это и есть алгоритм выполнения самой программы. А что такое алгоритм?

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

Когда перед Вами стоит решение очень сложной задачи, можно (и нужно) применить метод "декомпозиции". Суть метода заключается в разбиении одной сложной задачи на множество взаимосвязанных, маленьких и простых подзадач, решив которые в отдельности Вы получите необходимый результат. Здесь можно привести аналогию с веником. Весь веник целиком сломать очень трудно, но если его ломать по одному прутику, то все получится.

Четвертый этап метода проектирования программных сред заключается в записи созданного алгоритма в виде программы на определенно языке программирования.

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

Также в процессе тестирования программы используется "эталонное решение". Это решение поставленной задачи другим методом (например, математически), которое позволяет получить заведомо верные результаты вычисления. Причем в эталонном решении используются не единичные данные, а множество различных данных позволяющих охватить все возможные ситуации вычисления. На основе такого "эталонного решения" можно выявить все возможные "подводные камни" и ошибки программы или ситуации, в которых программа не будет работать должным образом. Также необходимо реализовать в своей программе "защиту от дурака". Это когда учитываются такие ситуации, для которых программа в принципе не предназначена. Например, ввод цифр в поле или переменную, предназначенную для хранения фамилии.

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

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

Переменные

Имена переменных

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

For i = 1 to 10 Step 1
For j = 1 to 10 Step 1
dmsTable(i, j) = i * j
Next j
Next i

Если нам нужно сохранить в переменную чей-то год рождения. Назовите переменную "vblYearsBorn", а не "A". Старайтесь чтобы имя переменной отражало суть тех данных для хранения которых она предназначена, чтобы оно было интуитивно понятно. Пусть от этого имя переменной будет немного длинным, но зато это не даст вам запутаться и исключит повторное использования данной переменной в других вычислениях, для которых она не предназначена. Имя переменной желательно обязательно начинать с прописных букв vbl, от английского variable (переменная). Это особенно актуально в Объектно-Ориентированном Программировании (далее ООП). Так как имя переменной можно спутать с названием, какого либо объекта на форме (об этом пойдет речь ниже).

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

После идентификатора, без пробелов, следует писать имя переменной. Его нужно начинать с большой буквы, чтобы при просмотре листинга программы Вы видели, что это переменная, или какой-то другой объект, чтобы буквы выделялись, а не сливались в одну строку.

Объявление переменных

Некоторые языки программирования (например, Visual Basic) позволяют работать с переменными не объявляя их в коде программы. Я считаю это большой ошибкой и не солидностью языка программирования (но это не значит что этот язык программирования плох)!

Объявление переменной это определение ее типа и имени.

Dim vblFirstName as String (Visual Basic)
Var vblFirstName: String; (Turbo Pascal)
Char vblFirstName; (C++)

Т.е. мы как бы указываем программе, что будем использовать переменную с именем vblFirstName и тип данных этой переменной String (текстовый/литеральный).

Почему это важно (это касается только тех языков программирования, которые разрешают так делать. Например, если Вы не объявите переменную в С++ или Turbo Pascal-е, при компиляции будет сгенерирована ошибка, что используемая переменная не объявлена)? Все очень просто. Если мы не объявим переменную ей автоматически будет присвоен тип Variant, это значит что в переменную можно будет сохранять данные почти любого типа. Во-первых, мы сможем записать в переменную, которая хранит фамилию числовые данные или наоборот. ЭТО НЕПРАВИЛЬНО! Так как фамилия не может содержать цифры. Мы заведомо делаем в программе брешь, возможность для совершения ошибки. Вот такими ошибками и пользуются хакеры для взлома систем и прочее. Во-вторых, тип, присваиваемый автоматически, очень "много" занимает места в оперативной памяти. А хорошая программа должна как можно меньше весить. И не важно, сколько гигабайт оперативки у Вас на компьютере. В-третьих, явное объявление переменных позволит назначить им тот тип данных, который Вам необходим. И Вам будет намного легче узнать, какие переменные уже используются в программе. Достаточно будет посмотреть в начале программного кода или модуля, какие переменные уже заданы, а не перелопачивать весь код программы. Вы никогда не сможете повторно объявить уже объявленную переменную в одном и том же модуле, или перепутать их имена, а значить не используете переменную в тех вычислениях, для которых она не предназначена.

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

Инициализация переменных

После того как Вы объявили переменную её необходимо инициализировать, т.е. присвоить ей какое либо значение или обнулить. Это очень актуально для переменных используемых в вычислениях. Дело в том, при объявлении переменной для нее выделяется (резервируется) память. Резервирование памяти не отчищает ячейки от значений, которые ранее в них хранились, поэтому если за объявлением переменной не следует её инициализация, то текущее значение этой переменной будет непредсказуемым, а не нулевым, как думают многие. Не обязательно, что именно так и будет, но если это произойдет причину неправильных вычислений порой трудно выявить, так как код программы верен синтаксически и логически, но все равно вычисления идут неверные.

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

vblSum = 0
For I = 1 to 10 Step 1
vblSum = vblSum + i
Next i

Или присвойте ей единицу, если переменная используется, как множитель или делитель.

vblSum = 1
For I = 1 to 10 Step 1
vblSum = vblSum * i
Next i

Если это строковая переменная просто отчистите ее.

vblFirstName = ""

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

Глобальные и локальные переменные

Все переменные имеют свою область видимости в зависимости от того, как Вы их объявили. Переменные могут быть локальными и глобальными.

Локальные переменные - это переменные объявленные внутри какой-либо функции (подпрограммы). Они видимы только в пределах данной функции и не могут быть непосредственно вызваны из основного текста программы. Когда выполнение программы возвращается из функции к основному коду программы или другой функции, локальные переменные удаляются из памяти.

Глобальные переменные - это переменные, определенные вне тела какой-либо функции (для ООП, переменные объявленные в модулях проекта). Эти переменные имеют глобальную область видимости и доступны из любой процедуры, функции в подпрограмме.

Очень часто возникают ошибки при использовании глобальных переменных.

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

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

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

Константы

О константах буквально в двух словах. С их использованием в программе также необходимо быть внимательным (как и вообще занимаясь программированием). Имена констант лучше всего начинать с трех буков con, от английского constant (константа).

Const conPi = 3.14159265

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

Структурное программирование

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

Операторы начала и конца цикла пишутся строго друг под другом, а все операторы внутри цикла чуть правее. Все отступы делаются с помощью табуляции (клавиша Tab). Точно также пишутся логические схемы. Благодаря такому написанию ваша программа становится более читабельной и легкой для восприятия. Также облегчается отладка программы. Вы можете сами сравнить приведенный ниже пример, написания кода по принципу структурированного программирования и без него. Пример приведен на языке Turbo Pascal (часть кода сортировки массива).

Пример "Структурированный код":

For i:=1 to 9 do
begin
vblMin:=A[i];
k:=i;
For j:=1+i to 10 do
begin
If (vblMin>A[j]) Then
begin
vblMin:=A[j];
k:=j;
end;
end;
vblStuf:=A[i];
A[i]:=vblMin;
A[k]:=vblStuf;
end;

Пример "Обычный код":

For i:=1 to 9 do
begin
vblMin:=A[i];
k:=i;
For j:=1+i to 10 do
begin
If (vblMin>A[j]) Then
begin
vblMin:=A[j];
k:=j;
end;
end;
stuf:=A[i];
A[i]:=vblMin;
A[k]:=vblStuf;
end;

Какой вариант более читабелен и понятен? Несомненно, первый.

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

Ошибки

Программы очень редко работают правильно с первого раза. Закон Мерфи гласящий "Если что-то плохое может случиться, оно непременно случиться", похоже, был написан как раз применительно к компьютерным программам.

Ошибки, возникающие в процессе работы программы можно разделить на несколько типов:

1. Синтаксические ошибки
2. Ошибки времени выполнения
3. Логические ошибки

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

Ошибки времени выполнения выявляются компьютером во время выполнения программы. Подобные ошибки имеют место, когда программа дает компьютеру указание выполнить неверную операцию (например, деление на ноль или манипулировать неописанными или неверными данными).

Ошибки ввода данных - также являются ошибками времени выполнения. Причиной таких ошибок является попытка ввести данные неверного типа (например, переменной целочисленного типа присваивается строковый параметр или число вещественного типа).

Логические ошибки имеют место, когда программа выполняет неверный алгоритм. Данные ошибки являются самыми коварными, их очень сложно выявить, потому что они не фиксируются при компиляции. Данные ошибки проявляются при выводе неверных результатов программой. Единственно возможные способы выявления таких ошибок это использование методов: "эталонного решения" и "ручной отладки".

Умелое использование всех этих методов и правил: метод декомпозиции, структурное программирование, метод проектирования программных средств, эталонное решение и другие, говорят о профессионализме.

Компьютер всегда прав

Самая раздражающая ситуация в программировании - когда код верный, но не работает. “Да тут три строчки, блин, просто негде ошибиться! Наверное баг! Пойду потрачу три дня на изучение баг-репортов компилятора/интерпретатора/фреймворка... ”. Возникает чувство, будто компьютер над вами издевается!

Тут главное помнить, что в этих трех строчках есть ошибка. Если код работает не верно - значит код написан не верно . Точка. Виноваты только вы. Универсальный совет - идите спать! Ну или хотя бы отвлекитесь на чашку чая. Когда, через некоторое время, вы вернетесь к коду, наверняка станет ясно, что тут лишний оператор отрицания, или перепутаны две переменные с похожими именами, или еще какая-нибудь мелочь, в которой мы никогда никому не признаемся.

Успокойся и все получится

Эмоции - наш злейший враг. Лично я, как вы уже догадались по количеству восклицательных знаков, человек эмоциональный. И мне, порой, бывает сложно сконцентрироваться на коде, особенно если этот код писал не я, и код не самого лучшего качества. Мозг как-то сам собой переключается на разработку особо изощренных методов пыток для автора кода.
Нужно заставить себя успокоиться. Нужно принять задачу не как издевательство над вашим мозгом, а как вызов. Да плохой код, да отсутствует документация, да сложно, но я программист, это часть моей работы и я справлюсь .

Самое сложное - начать

Бывает смотришь на задачу, и не знаешь как к ней подступиться. С какой стороны начать? И вообще, что-то лень сегодня. «Посижу 10 минут во Вконтактике, потом начну. Ну, после кофе. Ну вот, старый код надо порефакторить, и потом начну. А это что-за таск с низким приоритетом? Выполню его и точно начну…» .
Просто начните . Начните с любого конца. Разбейте задачу на мелкие части и начните выполнять их. Перестаньте откладывать, отбросьте посторонние мысли, сконцентрируйтесь на задаче, и начните работу. Дальше пойдет как по маслу.

Читай книги

Читайте книги. Я еще раз напишу: Читайте книги!
Почему-то многие программисты совершенно игнорируют книги. “Я и на работе отлично просвещаюсь ”, “У меня нет времени ”, “Я читаю статьи в интернете ”. Это все здорово, но лично я считаю, что лучший источник знаний - это все еще книги. Я стабильно покупаю по одной-две книги в месяц, плюс время от времени перечитываю что-то старое. Не буду врать, у меня на полке скопилась внушительная стопка того, что я купил, но пока не читал (как с играми в стиме) , но я дойду, обязательно дойду.

Знай свои инструменты

Не поленитесь выделить время на подробное изучение инструментов и технологий с которыми вы работаете. Это многократно окупится. Досконально изучите все возможности языка на котором вы программируйте. Просто возьмите, и прочтите официальную документацию от корки до корки. Не используйте IDE только в качестве редактора кода, в любой современной среде есть куча инструментов для повышения качества кода и вашей продуктивности. Не используйте фреймворк только как скелет архитектуры. Изучите его и он сэкономит вам уйму времени. Разберитесь в тонкостях системы контроля версий. Чем лучше вы знаете свои инструменты, тем больше работы они делают за вас .

Не будь перфекционистом

Выше я писал, что самое трудное - это начать. Так вот, закончить - тоже не всегда легко. Отлаживать и рефакторить код можно бесконечно. “Что-за длинный метод? ”, “Может это в отдельный класс? ”, “Было бы удобнее если бы... ”, “А вдруг потом понадобится... ”, “А вдруг... ”. В программировании нельзя быть перфекционистом. Проблема в том, что достаточно почитать Роберта Мартина или Банду четырёх, как тут же возникает желание переписать нафиг весь свой код. Нужно понимать, что идеального кода нет. Я придерживаюсь правила: “Код должен работать без багов, быть тестируемым и читаемым ”. Все. Пока код метода отвечает этому требованию, я его не трогаю. Даже если в нем два цикла, три условных оператора и четыре параметра.

Умей отдыхать

Самая большая проблема программистов в том, что мы любим свою работу. У меня в отпуске начинается ломка, неделя без программирования - и мне снится сон о том как я продумываю архитектуру нового приложения. Плюс программисту не сложно найти заказы на стороне, которыми можно заниматься по ночам. Плюс свои проекты. А сколько раз вы не могли уснуть, потому что мозг отказывался переключаться с задачи, которой вы занимались весь день?
Все это ведет к переутомлению, и, как правило, к снижению продуктивности. Отдохнувший программист - эффективный программист . Высыпайтесь. Найдите себе хобби, которое никак не связанно с мозговой деятельностью и посвящайте ему пару часов в день. Это позволит отвлечь мозг от работы, перезагрузить его. Самые интересные идеи и самые верные решения в последнее время приходят мне в голову в спорт-зале.

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

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

имена переменных – используйте имена переменных, отражающие их назначение. Они дополнят комментарии и помогут понять код, когда вы вернетесь к нему позднее;

имена функций – все вышесказанное относится и к именам функций. Они должны описывать выполняемые ими действия;

чем короче, тем лучше – во Flash нет ограничения на длину функции. Тем не менее, если вы напишите функцию длиной в 100 строк, позднее вам будет непросто ее редактировать. Лучше разбить функцию на задачи и поместить каждую задачу в отдельную функцию;

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

старайтесь обходиться без жесткого кодирования – под жестким кодированием подразумевается включение в ваш код конкретных чисел. Допустим, для описания правой стороны рабочего поля в вашем коде используется значение 550, оно будет жестко закодировано в программу. Если вы решите расширить рабочее поле до 600 пикселов, вам придется изменять каждое употребление значения 550 в коде. Лучше в самом начале задать переменной под названием screenRightSide значение 550 и использовать эту переменную на протяжении всей программы;

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

Отладка

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

Помимо использования отладчика ActionScript, отладку можно производить различными способами. При пробном воспроизведении ролика в окне Output могут появляться сообщения об ошибках. Иногда этого достаточно, чтобы вы поняли, в каком месте кода у вас проблемы 10 .

Информация о программе может также размещаться в окне Output при помощи команды trace. Она поможет вам отследить определенные моменты программы и значение некоторых переменных в эти моменты.

Если же вы хотите воспользоваться программой отладки, советуем вам изучить соответствующую информацию в руководстве по Flash MX. Программа отладки является простым инструментом, позволяющим отображать значения переменных во время воспроизведения Flash‑ролика. Однако она не в состоянии творить чудеса; программа отладки может только помочь вам разобраться в собственном проекте.

У меня тоже есть методички о программировании, даже по проектированию программ и разработке, так же в 1С, кое-что выложено здесь .

Я раньше работал доцентом в институте (впрочем до преподавания был админом, разбирался с 1С, поработал немного во франче но зарабатывал не много). После 5 лет преподавания сейчас уже 6 лет профессиональный 1Сник. Спустя шесть лет данной публикацией навеяло кое-что добавить.

Видел я разных студентов и учителей, программистов и начальников. Сам я постигал азы программирования с детства на коленке, курсов не кончал, а преподавал так - компилировал учебники и статьи из интернета, смотрел, показывал и делал видеокурсы, практическими заданиями правда все больше готовыми пользовался. По роду деятельности программистом после института и в возрасте уже нет особой возможности много учиться, так что я - программист из окопа, занимался по началу все больше оперативной деятельностью, много был на поддержке пользователей в чем не особо пригодилось чему учили и чему учил, так как на первом месте даже не качество а объем и скорость разработки, ну и соответственно умение в 100 процентов случаев достигать положительного результата. Даже если в текучке ошибся - пользователь напишет или сам позвонит и покажет, все такое в рабочем режиме без проблем устраняется. Очень полезная штука в организации труда на поддержке Битрикс, документооборот с заявками на ИТ. Вот если неправильно разработать метождику проекта или не до конца продумать, вот тут уж проблема может быть гораздо серьезнее.

Как-то вышло маститые сертификаты с меня не спрашивали, но первый руководитель отдела 1Сник был у меня Разработчик с большой буквы, который отличался глубоким знанием предметной области и умением делать абсолютно всё необходимое в работе, даже по админской части, все его очень уважали. Не было ни одного вопроса, который он не мог бы решить на предприятии.

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

В проектной деятельности больше всего помогает знание основ моделирования IDEF и чтение SAP ARIS (но рисовать схемы ARIS трудоемко). Всяко и прежде всего надо обязательно начинать проекты с продуманного ТЗ потому что без него понимание и общение с заказчиком проекта очень непросто складывается.

А программирование, что уж тут, 7 операторов да объектная модель... Оно и к месту, что статья такая коротенькая. Больше всего оказалось нужно для использования меня по назначению как 1Сника - выучить используемые на предприятии конфигурации, научиться помогать сотрудникам, помогать бухгалтерам, разбираться в коде, искать ошибки в учете... Ну и конечно на производстве в области программирования даже в оперативной деятельности, особенно как правило систем несколько (учетные, складские, транспортные,...), сложные задачи.

Так что теперь у вас есть проблема, если вы пишете библиотеку, которая будет использоваться как кодом старой школы, написанным с wchar_t , определённым как псевдоним для unsigned short , так и кодом новой школы, написанным с wchar_t как отдельным внутренним типом. Какой тип данных вам нужно использовать для строковых параметров?

Это перевод The sad history of Unicode printf-style format specifiers in Visual C++ .

Windows реализовала Unicode раньше, чем большинство других операционных систем. В результате решения Windows для многих проблем отличаются от решений, принятых теми, кто подождал, когда пыль осядет¹. Самым ярким примером этого является использование Windows UCS-2 в качестве кодировки Unicode. Тогда это была кодировка, рекомендованная консорциумом Unicode, потому что Unicode 1.0 поддерживал только 65"536 символов². Консорциум Unicode передумал пять лет спустя, но к тому времени было уже слишком поздно для Windows, которая уже выпустила Win32s, Windows NT 3.1, Windows NT 3.5, Windows NT 3.51 и Windows 95 - все из которых использовали UCS-2³.

Но сегодня мы поговорим о строках формата в стиле printf .

Это перевод If FlushInstructionCache doesn’t do anything, why do you have to call it, revisited .

Предполагается, что вы будете вызывать функцию FlushInstructionCache , когда вы генерируете или модифицируете исполняемый код в run-time - чтобы процессор при выполнении вашего сгенерированного/модифицированного кода читал бы написанные вами инструкции, а не старые инструкции, которые могут остаться в кеше команд процессора.

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

Но в Windows NT функция FlushInstructionCache выполняет реальную работу, поскольку ей необходимо уведомить все остальные процессоры о необходимости очищать их кэши.

Однако если вы посмотрите на Windows 10, то вы обнаружите, что функция FlushInstructionCache выглядит как версия для Windows 95: она ничего не делает .

В чём тут дело?