Жизнь и восстановление после StackOverflow

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

Дальше я расскажу, зачем и как можно обрабатывать ошибку переполнения стека, а так же какую «свинью» подложила EurekaLog — инструмент, который должен был обеспечивать нас информацией о том, почему клиент снова в бешенстве.

Сначала немного справочной информации о том, как устроен стек.

Устройство стека 

В каждом потоке под стек  резервируется по умолчанию 1 МБ адресного пространства. Зарезервированная память физически еще не выделена. Все адресное пространство разбито на страницы — минимальные блоки, которыми оперирует системный менеджер памяти. Стек растет от большего адреса к меньшему постранично. Память выделяется (становится commited) в момент роста стека. Для того, что бы определить необходимость выделения еще одной страницы из зарезервированных, используется защищенная страница памяти. Это такая страница, которая уже выделена (закомичена)  и помечена флагом Page_Guard. Защищенная страница всегда располагается следом за страницей, в которой находится текущая вершина стека. При росте стека происходит обращение к защищенной странице, система реагирует, снимается флаг Page_Guard со страницы и возбуждается исключение доступа к защищенной странице.  Обработав исключение система понимает, что необходимо выделить еще страницу памяти из зарезервированного пространства и пометить ее флагом Page_Guard. Уже выделенная память стека обратно не возвращается, и страницы остаются commited даже после полной раскрутки стека.
Последняя (в сторону роста стека) зарезервированная страница адресного пространства никогда не выделяется. Она служит буфером, что бы вершина стека не вышла за границы сегмента.

Механизм возбуждения StackOverflow 

В какой-то момент в процессе роста стека остается только одна защищенная страница перед последней зарезервированной. Приложение пытается нарастить стек. С защищенной страницы снимается флаг защиты и происходит попытка выделить еще одну защищенную страницу. Система не разрешает и возбуждает исключение переполнения стека (StackOverflow). Как правило, после этого у нас остается еще почти целая страница для обработки исключения.
С этого времени система снимает с себя ответственность за контроль стека. Page_Guard  в дальнейшем больше не выставляется страницам, и если стек снова достигнет предела, произойдет обращение к последней зарезервированной странице. В результате система убъет поток и приложение. Для пользователя — приложение просто схлопнется.

Почему StackOverflow это проблема

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

procedure FmtStr(var Result: string; const Format: string;
const Args: array of const; const FormatSettings: TFormatSettings);
var
Len, BufLen: Integer;
Buffer: array[0..4095] of Char;
begin
..
end;

Лишь один такой вызов израсходует всю оставшуюся доступную память для того, что бы расположить на стеке массив Buffer. 
В рабочем проекте мы используем EurekaLog для сбора информации о стеке исключений и формирования отчета об ошибке. Но при обработке исключения StackOverflow, эврика обращалась к методам rtl, которые не оставляли нам шанса узнать причину, почему у клиентов на проекте наш продукт в момент работы схлопывается.
Была еще одна причина, которая побудила решить эту проблему кардинально. Большую часть нашего продукта занимает скриптовый движок для исполнения паскаль скриптов. Клиентская логика пишется на паскаль скрипте. Паскаль скрипт динамически подгружается. Таким образом, если программист допустит ошибку при написание скрипта и получит StackOverflow, то не останется другого варианта как снова перезапустить развесистый фреймворк.

Обработка StackOverflow

В MSDN есть функция
  BOOL WINAPI SetThreadStackGuarantee(_Inout_  PULONG StackSizeInBytes);
с помощью которой можно установить размер памяти, который останется доступным после возбуждение StackOverflow для обработки исключения. Функция выполняет простую вещь. Если с помощью ее установить гарантированный размер 8 килобайт, то в этом случае система будет держать перед вершиной стека 2 защищенные страницы по 4 килобайта.  
Теперь мы можем гарантированно собрать информацию об ошибке. Эвристическим путем было выяснено, что для эврики надо 32 кБ. Для перестраховки мы задаем 64кб. Однако следующее переполнение стека будет фатальным. 
Но для полного восстановления после StackOverflow необходимо вернуть защищенные страницы. Когда это сделать? Когда стек свернется, и вершина стека уйдет со страниц, на которых мы хотим восстановить Page_Guard. При этом остается вероятность, что при обработке исключения переполнения стека, мы получим новое переполнение стека. Для этого сразу же после первого переполнения стека выставим на одной верхней странице флаг Page_Guard.  И в случае нового переполнения стека при обработке предыдущего, мы сможем хотя бы сообщить о переполнение стека при обработке переполнения стека и закрыть приложение.
Вот так это выглядит в теории:
На практике будут следующие шаги:
  1. Установить гарантированный размер для обработки стека равный 68 кБ;
  2. Необходимо повесить хук на возникновение исключения. В случае StackOverflow начать процесс восстановления. Установить на 1 страницу Page_Guard. В Delphi можно повесить для этих целей обработчик на System.ExceptObjProc;
  3. Дождаться раскрутки стека. Это самый интересный момент. Тут возможны разные варианты. Один из самых простых вариантов —  установка хука на оконные сообщения и на onIdle. В VCL приложение стек как правило всегда раскручивается до Application.ProcessMessage. Вот тут и попытаемся восстановить остальные 16 защищенных страниц;
  4. Если в момент восстановления стека, система возбудила новое исключение StackOverflow, то ничего не остается, как сделать хорошую мину: информируем пользователя об исключении и выполняем перезапуск приложения.
Приведу простейший пример восстановления после StackOverflow. Все начинается с Button1Click и секция initialization:
unit main;

interface

uses
Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes,
Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;

type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
procedure DoOnMessage(var Msg: TMsg; var Handled: Boolean);
end;

function SetThreadStackGuarantee(var StackSizeInBytes:
Cardinal): LongBool; stdcall; external 'kernel32.dll' name 'SetThreadStackGuarantee';
type
proc = procedure();
TRaiseExceptionProc = procedure(ExceptionCode, ExceptionFlags: LongWord;
NumberOfArguments: LongWord; Args: Pointer); stdcall;
TExceptObjProc = function(P: PExceptionRecord): Pointer;
var
Form1: TForm1;
oldRaiseExceptionProc: TExceptObjProc = nil;
restoringAfterStackOverlow: boolean = false;
stackGuaranteeSize: Cardinal;
const
PageSize = 4096;

function _RaiseExeceptionProc(P: PExceptionRecord): Pointer{Exception};
implementation

{$R *.dfm}

{$POINTERMATH ON}

function GetSegmentStackTop: Pointer; assembler;
type
NT_TIB32 = packed record
ExceptionList: DWORD;
StackBase: DWORD;
StackLimit: DWORD;
SubSystemTib: DWORD;
case Integer of
0 : (
FiberData: DWORD;
ArbitraryUserPointer: DWORD;
Self: DWORD;
);
1 : (
Version: DWORD;
);
end;
asm
MOV EAX, FS:[0].NT_TIB32.StackLimit
end;

function GetESP: Pointer; assembler;
asm
mov result, esp
end;

function GetMemoryInfo(addr: NativeUInt): TMemoryBasicInformation; inline;
begin
VirtualQuery(Pointer(addr), Result, SizeOf(Result));
end;

procedure TerminateRecoveringAfterStackOverflow;
begin
Assert(restoringAfterStackOverlow);
MessageBox(0, 'Не удалось восстановится после StackOverflow, приложение будет закрыто.',
'Все пропало',
MB_ICONERROR);
Halt(0);
end;

function RestoreStackPageGuard(APageAddress: Pointer): boolean;
var
oldProtectFlag: dword;
begin
result := VirtualProtect(APageAddress, PageSize, PAGE_READWRITE or PAGE_GUARD, oldProtectFlag);
end;

procedure StartRecoveringAfterStackOverflow;
begin
Assert(not restoringAfterStackOverlow);
restoringAfterStackOverlow := true;
RestoreStackPageGuard(GetSegmentStackTop);
Application.OnMessage := Form1.DoOnMessage;
end;

procedure StopRecoveringAfterStackOverflow;
begin
Assert(restoringAfterStackOverlow);
restoringAfterStackOverlow := false;
Application.OnMessage := nil; // Так конечно лучше не делать, а использовать для этих
// целей вместо обработчика OnMessage хук на сообщения
end;

procedure ValidateStackPageGuards;
var
memoryInfo: TMemoryBasicInformation;
address, stackLimit: NativeUInt;
guarded: Boolean;
begin
address := NativeUInt(GetESP);

guarded := False;
address := NativeUInt(GetMemoryInfo(address).BaseAddress);
stackLimit := NativeUInt(GetSegmentStackTop);


while not(guarded) and (address >= stackLimit) do
begin
memoryInfo := GetMemoryInfo(address);
guarded := (memoryInfo.Protect and PAGE_GUARD) = PAGE_GUARD;
address := address - PageSize;
end;

if not guarded then
begin
TerminateRecoveringAfterStackOverflow;
end;
end;


function _RaiseExeceptionProc(P: PExceptionRecord): Pointer{Exception};
begin
if (GetCurrentThreadId = MainThreadID) then
begin
if not restoringAfterStackOverlow then
begin
if Assigned(P) and (P.ExceptionCode = STATUS_STACK_OVERFLOW) then
begin
StartRecoveringAfterStackOverflow();
end
end else
ValidateStackPageGuards;
end;

if Assigned(oldRaiseExceptionProc) then
result := oldRaiseExceptionProc(P);
end;



procedure WeNeedToGoDeeper(var i : integer);
var
a:array[0..4000] of char;
begin
inc(i);
WeNeedToGoDeeper(i);
end;

procedure TForm1.Button1Click(Sender: TObject);
var
i: integer;
begin
i := 0;
try
WeNeedToGoDeeper(i);
finally
MessageBox(0, PChar(Format('На %d вложение',[i])), 'Ошибка StackOverflow', mb_ok);
end;
end;

procedure TForm1.DoOnMessage(var Msg: TMsg; var Handled: Boolean);
var
i: integer;
begin
Assert(restoringAfterStackOverlow);
ValidateStackPageGuards;

for i := 1 to 16 do
begin
if not RestoreStackPageGuard(Pointer(NativeInt(GetSegmentStackTop) + PageSize * i)) then
begin
TerminateRecoveringAfterStackOverflow();
end;
end;
StopRecoveringAfterStackOverflow();
end;

initialization
stackGuaranteeSize := PageSize * 16;
SetThreadStackGuarantee(stackGuaranteeSize);

oldRaiseExceptionProc := ExceptObjProc;
ExceptObjProc := @_RaiseExeceptionProc;
end.

Проверить, что восстановление после StackOverflow работает можно с помощью утилиты  vmmap из SysInternalsSuite.

Первый скриншот после запуска приложения. 16 кБ используется стеком из 1МБ. 68 кБ защищенная область.

Сразу после StackOverflow. Вся память выделена.
После восстановления работоспособности.

Более подробно о работе стека можно почитать тут:

  1. MSDN http://msdn.microsoft.com/ru-ru/library/windows/desktop/ms686774(v=vs.85).aspx
  2. У Джефри Рихтера в книге «Создание эффективных WIN32-приложений»
  3. У Марка Руссиновича в блоге http://blogs.technet.com/b/markrussinovich/archive/2009/07/08/3261309.aspx и книге «Внутреннее устройство Microsoft Windows»

Читать на сайте автора.

Предновогодняя задачка для разминки мозга

Пришлось тут на днях решать для студента (первого курса) задачку.Дословно выглядит вот так:2014 ACM-ICPC China Hunan Invitational Programming Contest
There is a simple problem. Given a

http://alexander-bagel.blogspot.com/2014/12/blog-post.html

SQLite в Delphi. Работа с LiteDAC #2

Как известно, для работы с различными базами данных в Delphi есть достаточно возможностей — от dbExpress до библиотеки FireDAC (ex. AnyDAC). Каждый набор компонентов по-своему

Читать на сайте автора.

Укрощение автопрокрутки

Люблю я Delphi. И нравятся мне в ней такие фичи, как: Ctrl+Shift+Enter (Find Local References), Ctrl+Shift+E (Refactor Rename), и многие другие. Вот окошки озвученных фич у меня расположены как-то так:
image
Мне так удобнее – слева от редактора кода. А когда результаты поиска большие (или список для рефакторинга большой) – то на экране так больше помещается. Есть один минус – при клике в строчку, которая не помещается на экране по ширине – происходит автоматическая прокрутка по горизонтали (на картинке выше такая строчка выделена подчёркиванием). Т.е. дерево уезжает влево и родительские узлы прячутся за прокруткой – меня это сильно отвлекает и раздражает.
Не секрет, что эти деревья реализованы на VirtualTreeView-компоненте, поэтому такое “лечится” в одно действие:

  VTV.TreeOptions.AutoOptions := VTV.TreeOptions.AutoOptions + [toDisableAutoscrollOnFocus];

Добавляем в пакет, устанавливаем – и готово!
Исходники доступны по ссылке.
P.S.: Однажды я писал, как боролся со шрифтом Object Inspector’а Delphi XE7. Чуть позже я доработал тот пакет, чтобы он исправлял шрифт и в остальных окошках/вкладках. Но оно не прижилось – среда время-от времени восстанавливает свой шрифт – получается вообще ерунда – шрифт скачет туда-сюда. Странное поведение. Но оно исчезает, если отключить модную тему оформления, которая установлена как обычный пакет (ModernTheme210.bpl). Отключить можно через реестр:
image
Отключив этот пакет, все иконки вернутся к старому стилю, зато IDE будет работать чуть стабильнее (у меня было несколько ошибок с указанием на ModernTheme210.bpl), и не надо мудрить со шрифтами.

Читать на сайте автора.

Собираем базу Android приложений разработанных с использованием RAD Studio

Частенько, в различных местах вижу просьбы "Покажите примеры приложений написанных с использование FMX" от разработчиков. Так совпало, что я решил немного освежить свои знания по

Читать на сайте автора.

Кроссплатформенный квест

Читать на сайте автора.

Заначка

 — что-либо прибережённое, припрятанное про запас ◆ Опять же всё расставив по местам, как и было, достал из-за трюмо тёткину заначку — вскрытую пачку «Любительских», — закурил. Андрей Битов, «Сад», 1960–1963 г. (цитата из Национального

http://alexander-bagel.blogspot.com/2014/11/store.html

Общее оформление файла

Эта заметка является продолжением к заметкам Стиль оформления кода. Вместо вступления, Настройки окружения и Регистр букв.

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

Копирайт

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

Следует разделять два уровня доступа к исходным текстам:

  • внутри компании (при создании и сопровождении проектов);
  • вне компании (при публикации в открытый доступ, либо при передаче третьим лицам).

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

Начало

В зависимости от своего типа, файл начинается с одного из зарезервированных слов: package, program, library или unit. Следом за ним, через один пробел, следует имя файла (без расширения) с точкой с запятой на конце. Например:

unit UnitName;

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

Это требование исходит из соображений: в случае последовательного просмотра файлов из «продвинутых» файловых менеджеров — имя файла всегда находится на одном и том же уровне от начала файла, а в случае отсутствия копирайта переход к имени модуля осуществляется всего в три клавиши: Ctrl+Home, Ctrl+Right.

Если файл имеет неявную для компилятора связь с другим текстовым файлом, который обрабатывается до (либо после) компиляции, то следующей строкой может идти комментарий вида:

// UnitName.xml

Это удобно для быстрого перехода к редактированию указанного в комментарии файла по сочетанию Ctrl+Enter.

Информацию о версии, даты создания и модификации, а также историю изменений можно вести в отдельном текстовом файле, сославшись на него аналогичным образом:

// UnitName.hst

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

Далее может следовать многострочный комментарий с описанием предназначения файла и нюансы его использования. Текст комментария обрамляется либо фигурными скобками { и }, либо парой (* и *) и отстоит от левого края на один отступ (см. пример). Однако вместо такого комментария рекомендуется использовать отдельный текстовый файл и его имя размещать в простом комментарии, например:

// UnitName.txt

После всех комментариев следуют директивы компилятора, относящиеся ко всему исходному тексту модуля. См. также: определения условной компиляции.

Секция uses

Зарезервированное слово uses занимает отдельную строку. Объявляемые далее модули группируются по принадлежности, а внутри группы располагаются в порядке использования (см. пример).

В секции implementation слово uses следует располагать после директив, относящихся ко всему разделу реализации модуля (см. пример).

Эта рекомендация следует из соображения, что секция uses может быть многострочной и имеет тенденцию к расширению. Съезжающие вниз директивы отвлекают внимание.

Секция interface

Все объявления из интерфейсной секции модуля доступны другим модулям и становятся глобальными. Поэтому секция interface должна быть максимально компактной и лаконичной, и не должна содержать объявления, которые не могут или не должны использоваться за пределами модуля. Это в особенности касается переменных, создаваемых автоматически при создании новых форм/фрейм:

var
  Form1: TForm1;

Такие переменные (за исключением единичных случаев) следует сразу удалять.

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

Секция implementation

Это секция реализации модуля. Она может быть пустой, либо содержать только код инициализации и/или финализации — это секции initialization и finalization.

Конец модуля

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

Директивы компилятора

Директивы компилятора, относящиеся ко всему исходному тексту модуля, располагаются перед интерфейсной частью между ключевыми словами unit и interface. Директивы, относящиеся к секции реализации модуля, располагаются сразу за словом implementation. Остальные директивы могут располагаться в тексте в любом месте, согласно правилам форматирования кода. (Также см. пример.)

Порядок объявления методов

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

При объявлении методов (в секции interface) сначала объявляются обработчики методов. Обработчики группируются по принципу их принадлежности — сначала обработчики формы (фрейма), затем обработчики остальных компонентов (Action’ов, кнопок, грида и т.п.). Внутри группы рекомендуется использовать порядок в соответствии порядка использования обработчиков в RunTime, т.е. сначала идут OnCreate, затем OnShow (или OnInit, OnLoadData, OnLoadState), а затем OnClose, OnDestroy (OnSaveState, OnSaveData, OnDone).

«Парные» методы можно располагать рядом, т.е. обработчики OnCreate/OnDestroy, OnShow/OnClose и т.п. Это удобно для контроля парности действий, выполняемых в таких обработчиках.

Для обработчиков событий Action’ов — сначала OnUpdate, затем OnExecute. Это положение вытекает из таких моментов:

  • Action.Execute всегда внутри себя сначала вызывает OnUpdate, а затем OnExecute, следование обработчиков в коде логично сопоставить с порядком вызова обработчиков. (Кстати, это документированная особенность TAction — обработчик OnExecute не будет вызван, если в OnUpdate свойство Action.Enabled сбрасывается в False.)
  • Читая код OnExecute часто приходится на какой-то момент переключаться на код обработчика OnUpdate, для глаз это удобнее делать, когда расстояние между обработчиками (ключевыми словами procedure) фиксированное. Как правило, код обработчика OnUpdate занимает одну-две строки, а код OnExecute может занимать и более 10 строк. Расположение обработчиков в порядке OnUpdate/OnExecute повышает скорость читаемости кода.

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

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

Пример

unit Example;
// Example.hst

(*
  Необязательное описание предназначения файла и нюансы его использования.
  Вместо данного описания рекомендуется давать понятные имена файлам, чтобы предназначение
  было самим-собой разумеющимся, а нюансы использования вытекали автоматически из интерфейсной части модуля.
  А в случае "раздувания" такого комментария его рекомендуется вынести в отдельный текстовый файл.
*)

{$I Common.inc}
{$ALIGN ON}
{$MINENUMSIZE 4}

interface

uses
  // Delphi units
  SysUtils, DateUtils, Windows, Classes, Forms,
  // My units
  MyUnit1, MyUnit2;

type
  TExample = class(TForm)
    procedure FormLocalize(Sender: TObject);
    // OnCreate, OnDestroy, OnShow, OnClose ...
  public
    constructor Create(AOwner: TComponent); override;
    destructor Destroy; override;
  end;

implementation

{$R *.dfm}

uses
  MyUnitA, MyUnitB;

{ TExample }

constructor TExample.Create(AOwner: TComponent);
begin
  inherited;
  // do something
end;

destructor TExample.Destroy;
begin
  // do something
  inherited;
end;

procedure TExample.FormLocalize(Sender: TObject);
begin
  {$include *.mui.inc}
end;

// OnCreate, OnDestroy, OnShow, OnClose ...

end.

Читать на сайте автора.

Регистр букв

Эта заметка является продолжением к заметкам Стиль оформления кода. Вместо вступления и Настройки окружения.

Регистр букв

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

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

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

Особым образом пишутся директивы компилятора (см. ниже).

Общее правило для идентификаторов

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

HINT: соглашение об именовании может содержать исключения из этого правила. Например идентификаторы вида: WM_ACTIVATE, DWORD, BITMAPFILEHEADER, some_table_filed и другие.

Если наименование идентификатора

то

Пример

1

состоит из одной буквы

допускается любой регистр

i, j, k: Integer;
s, t, u: string;
C: Cardinal;
D: TDateTime;

2

состоит из одного слова (в том числе аббревиатуры и сокращения)

начинается с заглавной буквы

Count
Value
Next
Rtti
Vcl
Db
Eof
Tmp
Src
Dst
Cnt

3

состоит из нескольких слов

слова пишутся слитно, каждое с заглавной буквы

FirstChar
DoSomethingElse
RttiContext
ItemsCnt

4

начинается с префикса, указывающего на тип идентификатора

префикс пишется строчными буквами

poScreenCenter
fsModal

btnOk
frmMain
acSetup

5

начинается с буквы, указывающей на вид идентификатора

буква пишется в верхнем регистре

SResourceString
EMyException
ISomeInterface
TAnotherType
FClassField
AMethodParameter
LLocalVariable

Директивы компилятора

Выбор регистра букв при написании директив компилятора сводится к простому правилу:

  • все однобуквенные директивы всегда записываются в верхнем регистре;
  • директивы, влияющие на текст компилируемого кода, записываются в нижнем регистре;
  • все остальные директивы — записываются в верхнем регистре.

Параметры всех директив пишутся в соответствии с общим правилом (см. выше).

Включение части кода из другого файла

Для включения (вставки) текста из указанного файла в текущий фрагмент кода при компиляции используется директива {$include} или {$I}.

Если включаемый файл содержит набор директив для компилятора и не содержит «полезный» код, следует использовать краткую форму написания в верхнем регистре:

{$I OurCompanyDefinitions.inc}

В противном случае используется полная форма, и записывается в нижнем регистре:

{$include SomeFileWithCode.inc}

Условная компиляция

Директивы условной компиляции кода, такие как {$define SomeSymbol}, {$ifdef SomeSymbol}, {$else}, {$endif} и т.п., пишутся в нижнем регистре.

См. также: определения условной компиляции.

Регионы

Редактор кода Delphi для удобства навигации позволяет сворачивать/разворачивать логические единицы исходного кода.

Для выделения произвольной части кода в сворачиваемую единицу используются регионы. Для этого необходимый текст обрамляется директивами {$region ‘Region Description’} и {$endregion}, которые пишутся в нижнем регистре. Описание региона (‘Region Description’) игнорируется компилятором, поэтому должно быть удобочитаемым и подчиняться правилам естественного языка.

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

Читать на сайте автора.

Настройки окружения

Эта заметка является продолжением к предыдущей.

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

Настройки окружения

Дизайн пользовательского интерфейса должен быть максимально однообразным. Для достижения этого при разработке форм необходимо выполнение следующих требований:

  • масштабирование текста в ОС Windows должно быть установлено в 100%;
  • тема оформления ОС Windows должна быть классической (с использованием шрифта Tahoma по умолчанию).

Масштабирование текста

При разработке форм в Delphi учитывается текущее разрешение экрана, а точнее параметр PPI — логическое количество точек на дюйм. Во время исполнения приложения, при создании формы, если текущее значение PPI не совпадает с тем, которое было сохранено в dfm-файле, происходит масштабирование.

К сожалению в VCL механизм масштабирования содержит ошибки. Подробно об этом описано здесь.

На уровне BaseForms.pas большая часть проблем исправлена, но новый механизм масштабирования требует, чтобы все dfm-файлы проекта разрабатывались в едином PPI. На текущий момент это значение должно равняться 96.

Это настройка операционной системы, называется «масштабирование текста». Чтобы PPI равнялось 96, масштабирование должно быть установлено в 100%.

Тема оформления

В разных темах оформления используются разные шрифты и разные размеры неклиентских элементов диалоговых окон (строка заголовка, граница окна, полосы прокрутки и другие). Это влияет на внешний вид разрабатываемых в Delphi форм (на разницу между значениями ClientWidth (ClientHeight) и Width (Height) формы, а также на высоту некоторых компонентов типа TEdit и TCombobox, для которых высота определяется по размеру шрифта). Использование разных тем оформления может привести к случайному/лишнему изменению свойств формы и её компонентов.

Классическая тема и шрифт Tahoma являются наиболее распространёнными в корпоративной среде, диалоговые окна и пользовательский интерфейс логичнее всего разрабатывать именно для них.

Настройки IDE

Настройки IDE Delphi — главное меню Tools Options. Эту настройку достаточно выполнить один раз, сразу после установки Delphi.

VCL Designer

Environment Options VCL Designer

VCLDesigner

Use designer guidelines необходимо сбросить.

Snap to grid – установить.

Grid size необходимо выставить именно в 4 и все компоненты располагать по сетке (Snap to grid) потому, что в Windows есть масштабирование. К числам, кратным 4, хорошо применяются стандартные масштабы текста – 75%, 125%, 150% и выше.

New forms as text – для того, чтобы новые dfm-файлы сохранялись в виде текстовых файлов; это необходимо при сравнении двух разных версий одного файла.

Auto create forms & data modules – выключено, т.к. формы создаются в Run-Time по мере необходимости.

Embedded designer – установить, настройка преследует две цели: а) избежать лишнего/случайного изменения положения формы (свойства Left и Top) в dfm-файл (когда программист просто подвинул форму, чтобы не мешала); б) вообще не сохранять эти свойства в dfm-файл (реализовано на уровне BaseForms – когда значения равны нулю, они не сохраняются).

Editor Options

Editor Options Display

Display

Right margin = 120 – значение 80 использовалось на старых мониторах; сейчас подавляющее большинство мониторов – широкоформатные, значение 120 является наиболее оптимальным как для чтения кода, так и по использованию экранного пространства. Именно это значение используется как максимально допустимая ширина строки в данном документе.

Остальные параметры на данной вкладке являются рекомендуемыми, но необязательными.

Formatter Options

Formatter Delphi Indentation

FmtIndentation

Formatter Delphi Spaces

FmtSpaces

Formatter Delphi Line breaks

FmtLineBreaks

Formatter Delphi Capitalization

FmtCapitalization

Formatter Delphi Align

FmtAlign

 

DDevExtensions

DDevExtensions – это расширение для IDE Delphi, скачивается и устанавливается отдельно со страницы: http://andy.jgknet.de/blog/ide-tools/ddevextensions/.

После установки необходимо выполнить настройку: IDE Delphi — главное меню Tools DDevExtensions Options.

Extended IDE Settings:

  • Disable alpha-sort class completion
    Эту настройку необходимо включить, т.к. данный документ вместо автоматического расположения методов в алфавитном порядке обязует это делать осмысленно — см. Порядок объявления методов

Form Designer:

  • Active
    Включить
  • Set TLabel.Margins.Bottom to zero
    Включить
  • Do not store the Explicit* properties into the DFM
    Включить

Пара комментариев

Первые два скриншота сделаны в Delphi 2010. От использования Delphi 7 мы отказались.

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

Насчёт масштабирования – на самом деле не важно, какое оно выставлено в системе. Важно, чтобы у всех членов команды оно было одинаковым (два момента: визуальное наследование и случайное/лишнее обновление dfm-файла). Есть ещё такой момент: определив его равным 100% я себе облегчаю задачу при описании правил создания пользовательских интерфейсов (grid size, размеры компонентов и расстояния между ними).

Читать на сайте автора.