We use this convention here at work; I also use it because it's clearer for me. However, for my personal code I will keep the begin on the same line as the else. At work, though, we put the begin on its own line as you show :)
Lübbe Onken I don't like that style, I use indenting more like this:
if SomeBoolean then begin // Code starts at the slash end else if SomeOtherBoolean Then begin // Code starts at the slash end else begin // Code starts at the slash end
Readability of code is more like quantum mechanics: on a wide range it can be said whether code is better readable or not, but when you look into finer grains it is a little bit more cloudy and depends more on personal perception and habits than on objective measurement.
I also will not use an indenting scheme in which the level of indentation is not identical to logical flow. In other words, another indent is only permissible if there is another if...then...else clause involved.
Borland style, set by default in formatter settings. Long ago I used K&R style in pascal, i. e.
if Foo then begin .... end else begin ... end
to make more code lines fit on the screen :) But since D2006, code completion puts begin on new line by default, so I started used default style and now another style seems unusual to me.
Andrea Raimondi Everything fine, I just wanted to prevent a discussion on "liking" a formatting style als opposed to giving a reason why you would put an else on a single line.
We study the source code that comes with Delphi a lot. We also buy all 3rd party components and libraries always with source code. If it is the preferred formatting style there, why should we introduce another style?
When I started programming in Pascal I really hated wasting a whole source code line just for a single "else". But meanwhile I "feel" a better readability of 3rd party source code if it is using the Borland Style.
I see only one agument for this, it's the formal logic. I call it also the stupid logic, because it's true by some formal criteria, but doesn't make any sence. There are two goals of code formatting. These are 1. To make a code easy to debug, 2. To make a code easy to read. In that respect
if SomeCriteria then begin DoSomething; end else begin DoSomethingElse; end;
is much better than
if SomeCriteria then begin DoSomething; end else begin DoSomthingElse; end;
because three bold words in one line end else begin is a nice visual delimiter, and three bold words each on a distinct line just look stupid. Come on guys, why do you ruin the beauty of pascal with this formal approach "we put begin and end on a distinct lines because it is so in c++"?
"Else" on its own line is clear delineation between two blocks of code, code running under opposing conditions. "Else" is a border; the begin and end are entry-exit points. Clarity.
Nick Hodges Having had the misfortune to work for a couple of years on a massive collection of chaotic code, I place a high value on formatting that is as transparent as possible to my mental processes. I also use CnPack, with its lines showing the block levels, but that is mostly of value on code I have inherited. ;)
Michael Thuma When the factors contributing to the boolean are many or complex, I use a local Boolean and do the logic separately. Readability and maintainability seem to me to require that.
Andrea Raimondi I am careful with IfThen(). Years ago, when I had to maintain a DLL written in C++ (a device interface), I found in some of their code a statement where each of the three terms in the conditional was too wide for me to read on the CRT. Perhaps they were just anticipating the advent of our 16:9 screens... ;) In C, that sort of thing should be considered totally unacceptable, as the original case for having the conditional op really was brevity. I have situations where there is a local boolean, and two named string constants, so the IfThen() remains terse.
I don't care as long as it can be mechanically applied. I use preprocessing and postprocessing steps in source control to reformat code when I have to (ie, when I can't live with the standard everyone else uses), even though with DelForExp that means pre-pre-processing because DelForExp will not remove linebreaks. Big deal, it adds a couple of seconds to each commit. But it saves hours of bickering about formatting. Assuming, that is, that the "standard" can be mechanically applied. Big assume.
Also, if you have a decent size monitor "how many lines" becomes less of an issue. At 1440 or 1600 pixels high you can get over 100 lines on the screen, so adding even 10 lines to a method by splitting "end else begin" is less of an issue.
More important are the other coding defects Nick talks about...
To add to Moz Le's comment, I had a conversation with Lachlan Gemmell a while ago where on a project that he was working on, all developers agreed to a certain format standard that was required for checking in code in the source code repository. This standard was enforced mechanically using the built-in code formatter in the later versions of Delphi. Developers were free to reformat the code to their own standard while programming but when they checked the code back in to source control, they applied the post-processing step to reformat the code back to the agreed standard. This meant that the differences between commits were not polluted with changes in coding styles and instead only included real code changes. To me it sounded like a good practice to use in teams where individual coding styles can't be reconciled.
Bill Meyer Agree with you. IfThen is bad. The first goal of code formatting is to make a code easy to debug. Some people make a common mistake writing if a then b; on a single line or, even worse, writing if a then b else c; all on a single line.
They argue: why not? the expression is short enought to place on single line. It's wrong because the code becomes harder to debug. When you write if a then b else c; you can place a breakpoint on the b line and on the c line, when you write all in one or two lines you can't do this, while the situation when you want to stop on a particular condition is common place.
Vitali Burkov I don't say that IfThen is bad; it has its uses, and certainly finds a place in my code. However, I do agree with your point about separate lines facilitationg debugging.
We use this convention here at work; I also use it because it's clearer for me. However, for my personal code I will keep the begin on the same line as the else. At work, though, we put the begin on its own line as you show :)
ReplyDeleteNot sure what the reason for it is though.
For me it's indenting. I prefer to spend an extra indent level for the begin/end so every else and else if appears in the same column, like
ReplyDeleteif SomeBoolean then
begin
...
end
else if SomeOtherBoolean
begin
...
end
else
begin
...
end
Same level of alignment of:
ReplyDelete1. begin..end blocks
2. if..else operators
I always use begin..end's, even for single statements, so for me it becomes:
ReplyDeleteif ThisIsTrue then
begin
...
end else
begin
...
end;
Lübbe Onken I don't like that style, I use indenting more like this:
ReplyDeleteif SomeBoolean then
begin
// Code starts at the slash
end
else if SomeOtherBoolean Then
begin
// Code starts at the slash
end
else begin
// Code starts at the slash
end
Andrea Raimondi Good that we are not starting an "I like this coding style more" discussion right now...
ReplyDeleteReadability of code is more like quantum mechanics: on a wide range it can be said whether code is better readable or not, but when you look into finer grains it is a little bit more cloudy and depends more on personal perception and habits than on objective measurement.
ReplyDeleteOh, I never argue code formatting. I'm totally a "To each his own" guy on that topic. ;-)
ReplyDeleteUse bad style but i learned from my mentor, so its in my blood.
ReplyDeleteif SomeBoolean then begin
//DoSome
end else begin
//DoSome
end;
I make only one argument on formatting: Use only formats which are supported by a formatting tool.
ReplyDeleteLübbe Onken it wasn't meant to be a flame :) rather, a simple statement :) that style works for me because I find it more natural :)
ReplyDeleteI also will not use an indenting scheme in which the level of indentation is not identical to logical flow. In other words, another indent is only permissible if there is another if...then...else clause involved.
ReplyDeleteBorland style, set by default in formatter settings. Long ago I used K&R style in pascal, i. e.
ReplyDeleteif Foo then begin
....
end else begin
...
end
to make more code lines fit on the screen :) But since D2006, code completion puts begin on new line by default, so I started used default style and now another style seems unusual to me.
Andrea Raimondi Everything fine, I just wanted to prevent a discussion on "liking" a formatting style als opposed to giving a reason why you would put an else on a single line.
ReplyDeleteBill Meyer - that's not a bad rule.
ReplyDeleteWe study the source code that comes with Delphi a lot. We also buy all 3rd party components and libraries always with source code. If it is the preferred formatting style there, why should we introduce another style?
ReplyDeleteWhen I started programming in Pascal I really hated wasting a whole source code line just for a single "else". But meanwhile I "feel" a better readability of 3rd party source code if it is using the Borland Style.
I always use:
ReplyDeleteif SomeCondition then begin
end
else begin
end;
I described my coding style in this document: http://wiki.overbyte.be/arch/IcsMidwareCodingStyle.pdf
I see only one agument for this, it's the formal logic. I call it also the stupid logic, because it's true by some formal criteria, but doesn't make any sence. There are two goals of code formatting. These are
ReplyDelete1. To make a code easy to debug,
2. To make a code easy to read.
In that respect
if SomeCriteria then begin
DoSomething;
end else begin
DoSomethingElse;
end;
is much better than
if SomeCriteria
then
begin
DoSomething;
end
else
begin
DoSomthingElse;
end;
because three bold words in one line end else begin is a nice visual delimiter, and three bold words each on a distinct line just look stupid. Come on guys, why do you ruin the beauty of pascal with this formal approach "we put begin and end on a distinct lines because it is so in c++"?
Vitali Burkov Funnily enough I've always preferred the latter for Pascal, and the former for C++.
ReplyDeleteJean-Marc Kiener It's my style too, and I don't think it's so bad. :)
ReplyDeleteIt's a compact and functional style.
"Else" on its own line is clear delineation between two blocks of code, code running under opposing conditions. "Else" is a border; the begin and end are entry-exit points. Clarity.
ReplyDeleteKyle Miller I can't quite get myself to agree to that :-)
ReplyDeleteAs you like coding conventions.
ReplyDeleteif SomeBoolean then
ShowMessage('True part')
else
ShowMessage('False part');
Nick Hodges Having had the misfortune to work for a couple of years on a massive collection of chaotic code, I place a high value on formatting that is as transparent as possible to my mental processes. I also use CnPack, with its lines showing the block levels, but that is mostly of value on code I have inherited. ;)
ReplyDeleteMichael Thuma Counter example:
ReplyDeleteIMsg := IfThen( SomeBoolean, 'TruePart', 'FalsePart' );
ShowMessage( IMsg );
Michael Thuma When the factors contributing to the boolean are many or complex, I use a local Boolean and do the logic separately. Readability and maintainability seem to me to require that.
ReplyDeleteMichael Thuma Bill Meyer I tend to use local booleans even for single conditions that may span across 2 lines.
ReplyDeleteAndrea Raimondi I am careful with IfThen(). Years ago, when I had to maintain a DLL written in C++ (a device interface), I found in some of their code a statement where each of the three terms in the conditional was too wide for me to read on the CRT. Perhaps they were just anticipating the advent of our 16:9 screens... ;) In C, that sort of thing should be considered totally unacceptable, as the original case for having the conditional op really was brevity.
ReplyDeleteI have situations where there is a local boolean, and two named string constants, so the IfThen() remains terse.
Bill Meyer I feel that readability is a major factor at all times :-)
ReplyDeleteI don't care as long as it can be mechanically applied. I use preprocessing and postprocessing steps in source control to reformat code when I have to (ie, when I can't live with the standard everyone else uses), even though with DelForExp that means pre-pre-processing because DelForExp will not remove linebreaks. Big deal, it adds a couple of seconds to each commit. But it saves hours of bickering about formatting. Assuming, that is, that the "standard" can be mechanically applied. Big assume.
ReplyDeleteAlso, if you have a decent size monitor "how many lines" becomes less of an issue. At 1440 or 1600 pixels high you can get over 100 lines on the screen, so adding even 10 lines to a method by splitting "end else begin" is less of an issue.
More important are the other coding defects Nick talks about...
To add to Moz Le's comment, I had a conversation with Lachlan Gemmell a while ago where on a project that he was working on, all developers agreed to a certain format standard that was required for checking in code in the source code repository. This standard was enforced mechanically using the built-in code formatter in the later versions of Delphi. Developers were free to reformat the code to their own standard while programming but when they checked the code back in to source control, they applied the post-processing step to reformat the code back to the agreed standard. This meant that the differences between commits were not polluted with changes in coding styles and instead only included real code changes. To me it sounded like a good practice to use in teams where individual coding styles can't be reconciled.
ReplyDeleteFrançois Piette
ReplyDeleteI also prefer your style:
if SomeCondition then begin
end
else begin
end;
Makes it very easy to distinguish the logical branches. IMHO, those begins do not deserve their own lines unless somebody is paid by linecount.
Bill Meyer Agree with you. IfThen is bad. The first goal of code formatting is to make a code easy to debug. Some people make a common mistake writing
ReplyDeleteif a then b;
on a single line
or, even worse, writing
if a then b else c;
all on a single line.
They argue: why not? the expression is short enought to place on single line.
It's wrong because the code becomes harder to debug. When you write
if a then
b
else
c;
you can place a breakpoint on the b line and on the c line, when you write all in one or two lines you can't do this, while the situation when you want to stop on a particular condition is common place.
Vitali Burkov I don't say that IfThen is bad; it has its uses, and certainly finds a place in my code. However, I do agree with your point about separate lines facilitationg debugging.
ReplyDeleteAfter 30 years, I've come to use the following, with varying levels of conditions and comments, but no rule without exception (not punny)...
ReplyDeleteif condition // why
then action // what
else other_action; // other what
if condition
then action
else begin
..code..
end;
if condition
then begin
..code..
end
else other_action;
if condition // why
and another condition // and why
then begin
..code..
end
else begin
.. code..
end;