2026-05-08 · By David Buch
Five Delphi habits worth changing in 2026
I open a lot of unfamiliar Delphi codebases. There are five things I find myself fixing every single time, and each is a one-paragraph fix. None of them are about the language being old or the tooling being awkward; all of them are about habits that crept in fifteen years ago and never got revisited.
1. Bare F-fields outside the constructor and destructor
Every method that touches an F-field directly is a method that has decided to bypass the property contract. That contract is the only thing standing between you and a class whose invariants nobody can predict. The rule is dull and easy: F-fields appear in the field declaration, the property declaration, the getter, the setter, the constructor, and the destructor. Nowhere else. Every other reference goes through the property name. Mechanical refactor; permanent benefit.
2. Useless setters
A setter whose entire body is FSomething := AValue; is not a setter, it is a typing exercise. Replace it with read FSomething write FSomething directly in the property declaration. You lose nothing: the field is still encapsulated by the property, the property still controls access, and you have one fewer method to step into in the debugger. Setters earn their keep when they validate, transform, or trigger side effects. If they do none of those things, they should not exist.
3. Exit deep in business logic
An Exit statement is a goto with marketing. It bypasses the structured-programming guarantee that a method has one entry and one exit, and the exit is at the end. The price you pay is that every reader of the code has to scan the whole method for the next surprise Exit before they can predict what runs and what does not. Replace each Exit with the appropriate IF/ELSE structure. The control flow gets more honest; the bug surface shrinks.
4. Anonymous procedures everywhere
Anonymous methods are useful in two specific places — the explicit teaching example in Chapter 19 of The Delphi Way, and the TProc/TFunc bodies that the parallel programming library API requires. Outside those carve-outs, replace every anonymous procedure with a named method. The codebase becomes greppable. Stack traces stop reading like Russian. The line in the debugger has a name; you can put a breakpoint on it. None of those benefits cost you anything.
5. Two-hundred-line methods
If a method does not fit on one screen, the reader cannot hold it in their head. Sixty lines is the upper end before reading becomes work. Split. Pull side effects into named helpers. The class’s public surface stays the same; the internal layout becomes scannable. Code-review velocity doubles for everyone who comes after you.
The compounding effect
Each of these is a small fix. Each takes minutes per file. The compounding effect is large — new developers join the codebase and read it without help; bugs become obvious in code review instead of after deploy; the tax on every change drops because the next change is no longer fighting the last five years of technical debt. The book covers all five in the relevant chapters, with worked examples and the rationale; this post is the bullet-point version. Try one of them on whatever you have open right now and see how the file reads afterwards.