Люблю я Delphi. И нравятся мне в ней такие фичи, как: Ctrl+Shift+Enter (Find Local References), Ctrl+Shift+E (Refactor Rename), и многие другие. Вот окошки озвученных фич у меня расположены как-то так:

Мне так удобнее – слева от редактора кода. А когда результаты поиска большие (или список для рефакторинга большой) – то на экране так больше помещается. Есть один минус – при клике в строчку, которая не помещается на экране по ширине – происходит автоматическая прокрутка по горизонтали (на картинке выше такая строчка выделена подчёркиванием). Т.е. дерево уезжает влево и родительские узлы прячутся за прокруткой – меня это сильно отвлекает и раздражает.
Не секрет, что эти деревья реализованы на VirtualTreeView-компоненте, поэтому такое “лечится” в одно действие:

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

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

Отключив этот пакет, все иконки вернутся к старому стилю, зато IDE будет работать чуть стабильнее (у меня было несколько ошибок с указанием на ModernTheme210.bpl), и не надо мудрить со шрифтами.

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

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

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

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

Копирайт

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

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

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

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

Начало

В зависимости от своего типа, файл начинается с одного из зарезервированных слов: 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.

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

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

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

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

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

• масштабирование текста в ОС 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

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

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

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

Formatter Options

Formatter Delphi Indentation

Formatter Delphi Spaces

Formatter Delphi Line breaks

Formatter Delphi Capitalization

Formatter Delphi Align

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, размеры компонентов и расстояния между ними).

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