6

I am working with Delphi. Does it make any difference in performance if we write if condition in different ways? For example:

if (condition) then
   someVar := someVal
else
   someVar := someOtherVal;

Or we can write:

if (condition) then begin
   someVar := someVal;
end else begin
   someVar := someOtherVal;
end;

I prefer the second option just because it looks better than the first one.

Himadri
  • 2,922
  • 5
  • 32
  • 56
  • 10
    "end else begin" is considered incorrect according to the object pascal style guide. http://edn.embarcadero.com/article/10280#8.2.3 – Chris Thornton Jun 30 '10 at 11:17
  • If you're concerned about performance, consider this: http://stackoverflow.com/questions/2679186/most-hazardous-performance-bottleneck-misconceptions/2679514#2679514 – Mike Dunlavey Jun 30 '10 at 12:51
  • 9
    @Chris: which is a good example of a style guide, but not the end all and be all of good code layout. There are good readability arguments to use the end else begin on one line style. I'll find the link if you are interested. And while I know the style guide actually uses the terms correct and incorrect, it is an entirely subjective matter which should never have used these terms in the first place. – Marjan Venema Jun 30 '10 at 13:03
  • 3
    The Object Pascal Style Guide is a standard you can adopt or not. Inside that standard, there are constructs that are considered "correct" and other "incorrect", why use other terms? That does not mean you can adopt other standards, if you like. There are projects where you can't commit code which does not follow the adoptes standard, that's "incorrect" and not allowed. It is true code formatting has nothing to do with the OP question, and the code syntax is correct, which is what matters here. –  Jun 30 '10 at 13:40
  • 3
    @Idsandon: by using terms such as correct and incorrect, you are implying that there is a good way to code and a wrong way to code, instead of "simply" a desirable way and an undesirable way. To me that is a very important distinction to make. In matters of preference there is no correct or incorrect. – Marjan Venema Jun 30 '10 at 14:03
  • 1
    You've missed the point, @Marjan. Implying that there are good ways and wrong ways to code is *exactly* what a style guide is supposed to do. The part you missed is that they're good or wrong *within the scope of the style guide*. No style guide can be applied universally, but if you've made the decision to adhere to a guide's rules for some project, then it's possible for that project to contain incorrectly styled code. A style guide that prefaces all its rules with "please" won't be followed. A style guide's rules must be commands, not polite requests. – Rob Kennedy Jun 30 '10 at 16:28
  • 3
    @Rob: No I didn't miss that part of Idsandon's point. The point I am making is that by using "incorrect" you incur all the connotations that go with that word. While Chris did say "is incorrect according to the style guide", that last bit often gets dropped or isn't heard. And that's when people tend to get very defensive. And unecessarily so. Which is why I object to the "shorthand" use of correct and incorrect. Make it "incorrectly styled" or whatever, but keep the nuance that it is the style that is correct or incorrect, not the code. – Marjan Venema Jun 30 '10 at 17:57
  • @Rob: No, a Style Guide is intended to ensure/enforce consistency in the belief that consistency of style is intrinsically A Good Thing. Therefore, adherence to the Style is "correct", whilst non-compliance is "incorrect". The validity of the rules and guidelines in the style itself are - ime - sadly entirely arbitrary, because no matter how good any one "reference style guide" is, someone will think they know better and come up with their own variation. Effective coding standards should be expressed in terms of outcomes, not inputs.... i.e. "write code clearly" not "indent by 2 spaces" etc – Deltics Jun 30 '10 at 20:40
  • Hey guys... Somebody with nothing better to do says "I think I'll write a style guide". Well OK, that's fine. He/she can even say (effectively) "In my opinion it is incorrect not to do it this way." It's an opinion, which may even have a bit of a reason behind it, but that's all it is. (Sorry to chime in on this - I was raised in a religion that says it is an "Error" not to agree with it. I don't care for that kind of assertion. ;-) – Mike Dunlavey Jun 30 '10 at 23:24
  • Hi Mike, hopefully you're always the most senior person on the totem pole wherever you work, or you'll have to deal with those people telling you what to do. Arguments about indentation are a frequent thing on many teams I have worked on. I wonder if that kind of thing is why the Go developers just made formatting required and part of the tooling. You don't format it right? We fix for you. No fighting. – Warren P Sep 28 '16 at 20:56

4 Answers4

24

No, there is no difference in performance, the code created will be identical.

An aspect that might be more important than that the second option looks nicer, is that it is better for maintainence. If you need to add another statement in the else block, you will not accidentally forget to add the begin and end, which would put the statement outside the if and always be executed.

Guffa
  • 687,336
  • 108
  • 737
  • 1,005
  • 2
    If you use proper indentation and know what you are doing, how could you possible "accidentally forget to add the begin and end"? I could spot missing `begin`s and `end`s in my sleep! – Andreas Rejbrand Jun 30 '10 at 20:10
  • 5
    @Andreas: Everyone is not as sharp as you are, and most people have those off moments that you seem to never have. ;) Writing maintainable code is not about writing something that you can maintain, but writing something that most programmers can maintain. My favorite quite come to mind: http://stackoverflow.com/questions/1103299/help-me-understand-this-brian-kernighan-quote – Guffa Jun 30 '10 at 20:49
  • 1
    People who never make mistakes, by their own accounting... .... well. There are some accounting flaws, for sure. :-) – Warren P Jul 01 '10 at 14:24
3

This will not make a difference in performance.

begin and end tell the compiler where a block of code starts and finishes, but no computation needs to be done there.

Miel
  • 3,347
  • 2
  • 26
  • 39
2

Begin and End do not slow down your code, as others have already said. I am writing another answer to encourage you even more explicitly to ALWAYS use begin and end whenever you could use them.

It is good to be liberal with using Begin and End, and not worry about them slowing you down (because they don't).

If you go the other way, and leave out begin and end wherever you can, you get into a different type of trouble.

This has happened to me lots. You can get in trouble when you insert a line into a place where no begin and end statement exist. You then end up scratching your head wondering what you did that broke your code. Begin-end-everywhere, even where not needed, is standard operating procedure for a lot of Delphi coders.

Warren P
  • 65,725
  • 40
  • 181
  • 316
  • 1
    I never use `begin ... end` when they are not necessary. This makes the code a lot more readable. I have never encountered a problem with this - no bugs, no head-scratching, no problems. I cannot see any reason for an experienced Delphi developer not to skip unnecessary`begin ... end`s. If you only indent your code correctly, and are aware of the phenomenon of the "dangling else", then nothing can go wrong. (I have developed in Delphi since the age of 12, so I know the langauge instinctively.) – Andreas Rejbrand Jun 30 '10 at 20:03
  • 3
    I can see at least one reason why an experienced Delphi developer might use unnecessary begin...end: He might have coworkers that are not as experienced. (And besides: I think of myself as quite experienced and I actually do use them quite often. Maybe I am not as experienced as I think or maybe your statement is just wrong.) – dummzeuch Jul 01 '10 at 10:09
  • As anyone reading can see, people disagree, and the matter is very very small, and of little final significance. You must learn to fix the problem of the dangling-else when it occurs, and you must do what you think is best, when you write your code. When you work with a team of developers, hopefully you can all come to an agreement. – Warren P Jul 01 '10 at 13:10
1

The only thing you should keep in mind about if-elseif-else is to keep the common cases up in your code before edge cases, so that the least possible conditions are evaluated.

gblazex
  • 49,155
  • 12
  • 98
  • 91