Take 10 developers and let them all hand-formatter some sample source-codes and you will get 10 different results.
Most developers have developed their own style in formatting source code because they are working alone and nobody else would see the code. Perhaps you are new to Delphi and used another programming language for many years. I can not remember what Delphi version was this first with an included formatter CTRL+D. Perhaps before that, you are using an IDE plugin or external program.
If you are working alone - do whatever you like with your source-code, but if you have to work together with other developers in a team - it's time to think about "your" formatting.
Some developers like many empty lines and indent nearly everything or want to have a description with a Date, Name, and Copyright over every method. Other developers hate empty lines and only ident one space.
Perhaps you have the "begin" at the end of the line and the "end" at the first position like:
if A > B then begin
But since the IDE has Castalia or perhaps you are using a third-party-tool you got the funny colored helper-lines to show the corresponding begin-end's, it is better that begin-end has the same ident.
Is there a right way to format your source-code? You may have the standpoint - only the default formatter-settings are the right way.
Keep in mind - if you are writing a program, you will read more source code then you write or in other words writing source code is not the trick, writing source code that could be read easily and by other developers too, is the goal.
Of course, the formatting is just the start, the next topics are caps, spaces and naming. There are so many rules out in the field.
Class fields have an "F" at the beginning, parameters an "A", local var's an "L". Perhaps you like to mix your local language with English (better not). Are you rename all your visual controls?
Label1 -> lbName
Edit1 -> edName
Edit1 -> edName
Edit1 -> NameEdit
Do you like long var-names "Name_of_the_person" ( hope not with "_" )
So where to start?
In the next day's I will try to introduce some of these rules to a team of four very different developers. Let's see if I can create a set of rules that everyone can live with.
But that will eventually be a topic for another blog post.