Syntax

If you look at Delphi source code, you will notice that it is dominated by words rather than symbols. Code appears inside a begin...end block rather than inside symbols like curly brackets ({..}) as in other languages.

Typically, code flows from top to bottom and from left to right. This implies that variables, objects, constants, and other elements need first to be declared before they are used (with the exception of forward declaration of classes).

Delphi is case insensitive, meaning that coding elements like variables, objects, methods, and the like can be declared in small or capital letters or in a combination of both. For example, the following declarations are all valid in Delphi: delphiBook, delphi_Book, DelphiBook, DELPHIBOOK, delphiBOOK. There are naming rules which prohibit the use of specific characters (e.g., an identifier cannot start with a number, etc.), but the limitations are very few, and, practically, when you code in Delphi, it is not common to come across them.

A notable difference with other languages is the operator to assign values to variables. In Delphi, a colon followed by the equal sign (:=) is used for this purpose, and the simple equal sign (=) is used to test equality in expressions.

Lastly, a convention that survived from the classic Pascal is the way the end of code line is declared in Delphi. Most of the lines of code end with a semicolon (;) with the exception of keywords (e.g., begin...end, if...then, while...do, etc.) and the last keyword in a code file. Every code file ends with the keyword end followed by a period (end.)

Programming Paradigms

Delphi is a fully developed object-oriented programming (OOP) language but does not force any specific development paradigm. You are free to use the OOP approach, but if, for some reasons, you prefer to use pure procedural programming, Delphi can fully support you. In fact, a huge part of the native libraries in Delphi come as procedures rather than embedded in objects and classes. This stands for Windows API calls, but, as the language is moving to cross-platform code, more libraries come in classes and records.

Compilation to Native Code

The final artifact of compilation of Delphi code is binary files with native code. In computing, this means that the final files represent machine code instead of an intermediate form like the one you find in virtual machine bytecode other languages produce. As a result, the executables run directly on top of the operating system without any translation layers between the executables and the underlying APIs of the operating systems.

Visual Applications

Delphi provides two out-of-the-box frameworks to support the development of visual applications: the Visual Component Library (VCL) and, starting from Delphi XE2, the FireMonkey (FMX) framework . VCL is used for Windows applications only, and FMX provides cross-platform components to build graphical user interfaces. Apart from VCL and FMX, there are third-party frameworks and libraries available to enrich the development of visual applications.

One Code Base for Multiple Platforms

One of the most distinguished characteristics of modern Delphi is the ability to produce binaries for multiple platforms from the same code base. At the time of writing, there are very few development tools in the market that truly support this. This means that, as a developer, you write code without any considerations as to which platform it will compile to, and Delphi takes the task to produce the appropriate executables or libraries for the platform of your choice. Currently, Delphi supports the following platforms: Windows 32-bit, Windows 64-bit, macOS 32-bit, macOS 64-bit, Android 32-bit, Android 64-bit, iOS, iOS 32-bit, iOS 64-bit, iOS Simulator, and Linux 64-bit. It is worth mentioning that although you can create applications for all the preceding platforms, the development is done on Windows only; that is, the compilers are Windows programs themselves.

Project Files

A program in Delphi has one source code file saved under the name of the application and with the .dpr extension. The code starts with the program keyword followed by the name of the application, and it has one main block of code enclosed in the begin..end keywords. The last end keyword is followed by a period (end.), and this signifies the end of the code file. Any text that appears after this generates a warning, but it is ignored by the compiler.

Delphi also generates a file with the .dproj extension. This file holds vital information about the cross-platform configurations, and it can also be used when the compilation of code is streamlined to MSBUILD.

There are a number of other support files with different extensions (e.g., .local, .deployproj) you may find, but they are not vital for the correct compilation of a Delphi program, or the compiler can regenerate them automatically.

Units

You can, very easily, create one big file and store all your code in it (with the exception of visual elements like forms and frames). Delphi will not complain and will compile your code correctly. However, this does not sound something that scales up easily when you write complex software. Instead, common practice suggests to organize your code in smaller separate files or modules as they are known in software engineering.

Delphi is a modular language and provides support to modules via unit files. In Pascal world, the term unit is used instead of module. The term module still exists in Delphi, and it refers to a special component (TDataModule) which sits in its own separate unit file. A unit is a separate code file, it has the .pas extension, and it is linked back to the project and is compiled to a binary file with the extension .dcu. DCUs are more important than the source code files because the compiler is able to use a .dcu file without the need to locate and access the corresponding .pas file. The downside is that DCU files are tightly linked to the version of the compiler that was used to create them. There were some exceptions in the past, but this is the general rule.

The uses clause can appear either in the interface or the implementation part of a unit.

Forms and Frames

A form in Delphi is a representation of the typical window you see in visual applications. If you want to add a label or an edit field in the window, you add them in a form, and, when the code is executed, you see a window with the components.

Delphi creates two files for each form: a typical .pas file which contains all the declarations and any custom code you want to add to alter the behavior of the form and a .dfm (in VCL) or .fmx (in FireMonkey) file which holds information about the components in a form. A valid form needs both files.

Frames are very similar to forms with the difference that they do not represent stand-alone windows and they do not have system menus and icons. A frame can be embedded in forms or in other frames to build more complex and reusable user interfaces. In terms of files, frames use the same file structure as forms.