但深度最多只能16层, 虽然是个限制, 但以正常的情形来说, 这应该已经足够了。
有些Compiler directives不应写在Unit中
对于像是{$MINSTACKSIZE}{$MAXSTACKSIZE}管理堆栈大小, 或者像是{$APPTYE}指示程序编译成图形/文字模式的Compiler directives, 只能写在.DPR中, 写在Unit中是没有效果的。
建议事项
确定您了解指令的影响
由于编译指令的影响是如此直接与深远, 在修改与应用某一个Compiler directive时,请确定您已经了解其含意与影响。
打开全部的侦错开关
Delphi有关侦错的Compiler directives如下:
? $HINTS ON
? $D+
? $L+
? $Q+
? $R+
? $WARNINGS ON
各指令的用法您可以参阅本章稍后对个别指令的说明, 全部打开这些开关吧! 这样不仅让您可以使用Delphi IDE的除错器, 对于程序编译与执行过程中的问题, Delphi也会适时的反应, 有助于写作正确的程序。
此处有一个迷思有待澄清-「加入Dubug信息会不会让执行文件变大变慢啊?」, 不一定。对于们像是$D+, $L+, $HINTS ON这些开关, 打开后, Delphi在编译时的确会额外加入一些除错信息, 使得.DCU的档案变大, 对于.EXE的档案大小并没有影响; 同时, 程序的执行速度也没有改变, 还可以应用IDE的除错器trace我们的程序, 值得应用。对于像是$Q, $R等Compiler directive, 的确会影响执行文件的大小与速度, 然而这并
不动摇我们在研发期间使用它们的决定, 请想想看, 值得为这一点点的速度放弃程序的正确性吗? 当然, 程序开发完成后, 正式出货的版本, 可以关闭这两个开关。

如果您写好了一个组件, 而且只预备提供.DCU, 由于没有.PAS可供Delphi IDE的Debugger追踪程序, 除错开关反而应该在组件脱手前关闭并重新编译.DCU, 否则会引起使用者那边找不到档案的例外讯息。
善用{$I}
{$I FileName}是一个非常有用的Compiler directive.应用这个指令, 我们可以弹性的管理Compiler directive的设定。
条件名称请加入前导符
不知道您有没有这个疑问 — 如果用{$DEFINE}定义的条件名称与变量名称相同时会发生什么事?
procedure TForm1.Button1Click(Sender: TObject);
var
TEST: integer;
begin
{$DEFINE TEST}
{$IFDEF TEST}
ShowMessage(’Test’);
{$ENDIF}
end;
以上的程序编译与执行都没有问题, 但条件名称与变量名称重复毕意容易让人混淆, 因此, 假如能适当的为编译条件名称之前加上诸如底线(_TEST), 程序会比较容易阅读。
设定一致的编译环境
在您了解了Compiler Directives之后, 请立即开始着手修改您IDE中有关编译指示的各个开关并且设为Default, 这样, 日后您的项目乃至整个研发小组都将拥有共同一致的编译环境, 对于写出来的程序会以何种方式编译连结都了然于胸, 直接有助于子系统顺利并入主系统中。
个别指令说明
有了之前对于Compiler directives的观念之后, 接下来的这一节我将一一介绍几个常用的Compiler Directive的用法与注意事项, 您可以从这一节中学到更多有关Compiler directives的知识与使用细节。
{$A+} 字段对齐
在{$A+}(默认值)的情形下, 如果没有使用 packed 修饰词宣告的 record 型态, 其字段会以CPU可以有效存取的方式向 1. 2. 4 等边界对齐,
以获取最佳的存取速度。以下列的程序示例来说:
{$A+}
type
MyRecord = record
ByteField: byte;
IntegerField: integer;
end;
…
procedure TForm1.Button1Click(Sender: TObject);
begin
ShowMessage(IntToStr(SizeOf(MyRecord)));
end;
ShowMessage在{$A+}时显示的结果是:「8」; 倘若是{$A-}, 那所得的结果是「5」,

按理说, Byte应该只要一个byte就足够了, 但是考虑到硬件的执行特性,
经过对齐后的record会有比较好的执行速度。
有关这个Compiler Directive要注意的事项是: 不管{$A}的开关是ON或OFF,
使用packed修饰过的记录宣告, 是一定不会对齐的. 例如: