Take 10 developer and let them all hand-formatter some sample source-codes and you will get 10 different results.
Most developer has developed their own style in formatting sourcecode, 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 Delphiversion was this first with an included formatter CTRL+D. Perhaps before that, your 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 developer 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 line and the "end" at the first position like:
if A > B then begin
But since the IDE has Castalia or perhaps your 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 sourcecode then you write or in other words writing sourcecode is not the trick, writing sourcecode that could be read easy and by other developers too, is the goal.
Of course the formatting is just the start, next topics are caps, spaces and naming. There are so many rules out in the field.
Class fields has 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 this rules to a team of four very different developers. Let's see if I can crate a set of rules that everyone can live with.
But that will eventually be a topic for an other blogpost.