Should I use block identifiers ("end;") in my code?

Question

Code Complete says it’s good practice to always use block identifiers, both for clarity and to protect the dimension.

Since I read this book, I did it religiously. Sometimes this seems excessive, though, as in the case below.

Does Steve McConnell really insist on always using block identifiers? Which ones would you use?

//naughty and brief with myGrid do for currRow := FixedRows to RowCount - 1 do if RowChanged(currRow) then if not(RecordExists(currRow)) then InsertNewRecord(currRow) else UpdateExistingRecord(currRow); //well behaved and verbose with myGrid do begin for currRow := FixedRows to RowCount - 1 do begin if RowChanged(currRow) then begin if not(RecordExists(currRow)) then begin InsertNewRecord(currRow); end //if it didn't exist, so insert it else begin UpdateExistingRecord(currRow); end; //else it existed, so update it end; //if any change end; //for each row in the grid end; //with myGrid 

Answer 1

Personally, I prefer the first, because IMHO "end"; don't tell me a lot, and as soon as everything is close, I can tell by identifier what happens when.

I believe that blocks are more useful when there are large operators. You can do a mixed approach where you insert a few "begin ... end;" s and comment on what they end up (for example, use it for with and first if).

IMHO you can also break it down into other methods, for example, part

  if not(RecordExists(currRow)) then begin InsertNewRecord(currRow); end //if it didn't exist, so insert it else begin UpdateExistingRecord(currRow); end; //else it existed, so update it 

may be in a separate method.

Answer 2

I always adhered to the style of a well-established and verbose , with the exception of unnecessary additional comments in the end blocks.

Somehow, it makes more sense to be able to look at the code and make everything faster from it than to spend at least a couple of seconds before deciphering which block ends there.

Tip : Visual Studio KB shortcut to start and end C #: Ctrl +]

If you are using Visual Studio, then having curly braces for C # at the beginning and end of the block also helps in that you have a KB shortcut to go to the beginning and end

Answer 3

I would use what my company has set for its coding standards.

Saying, I would prefer to use a second, more detailed block. It is much easier to read. However, I could leave aside comments that end in a block.

Answer 4

I think it depends on the situation. Sometimes you just have a method like this:

 void Foo(bool state) { if (state) TakeActionA(); else TakeActionB(); } 

I do not see how it looks like this:

 void Foo(bool state) { if (state) { TakeActionA(); } else { TakeActionB(); } } 

Improves readability in general.

Answer 5

I am a Python developer, so I don't see the need for block identifiers. I am happy without them. Indentation is enough for me.

Answer 6

A block identifier is not only easier to read, the less likely it is to be error-prone if you change something in the if else logic or just add a line and don’t understand that the line is not in one logical block, and then the rest of the code.

I would use a second block of code. The first one looks more beautiful and more familiar, but I think this is a language issue, not block identifiers

If possible, I use checkstyle to ensure the use of parentheses.

Answer 7

If I remember correctly, CC also gave some advice on comments. Especially not to rewrite the code in the comments, but explaining why he does what he does.

Answer 8

I would say that he is right only for the sake of the fact that the code can still be correctly interpreted if the indentation is incorrect. I always like to find the start and end block identifiers for loops when I look at the code and don't rely on the right indent.

Answer 9

It never happens anyway. Since I trust myself, I would use a shorter, more subtle style. But if you are in a team environment where not everyone has the same skill and technical support is important, you may want to choose the latter.

Answer 10

My reaction to the knee-jerk reflex will be the second listing (with repeating comments removed from the end of the lines, as everyone said), but if I thought about this more deeply, I would go with the first plus or two-line useful comment in advance, explaining what happens (if necessary) . Obviously, in this toy example, even commenting on the brief answer is probably not needed, but in other examples it can.

With less (but still readable) and easy to understand code on the screen, you can save space for the brain in future parts of the IMO code.

Answer 11

I am with those who prefer more concise code.

And it seems that the preferred version for the short version is more of a personal choice than universal suitability. (Well, inside a company, this can become a (mini) universal rule.)

It looks like excessive parentheses: some people prefer this as (F1 and F2) or ((not F2) and F3) or (A - (B * C)) < 0 , and not necessarily because they are not aware of the rules priority. For them it becomes more clear.

Answer 12

I will vote for a happy environment. The rule that I would like to use is to use bracketing keywords at any time when the content is multiple lines. In action:

 // clear and succinct with myGrid do begin for currRow := FixedRows to RowCount - 1 do begin if RowChanged(currRow) then begin if not(RecordExists(currRow)) InsertNewRecord(currRow); else UpdateExistingRecord(currRow); end; // if RowChanged end; // next currRow end; // with myGrid 

Answer 13

end comment is really useful for html-like languages, so invalid C code, like endless if / else / if / else sequence

Answer 14

frequent // comments at the end of lines of code (for example Well Behaved and Verbose) make the code more difficult to read imho - when I see it, I end up looking at the “obvious” comments, creating something special that usually isn’t There .

I prefer comments only where the obvious is not (i.e. general and / or unique functionality)

Answer 15

Personally, I recommend always using block identifiers in languages ​​that support them (but follow your coding company’s standards as @ Muad'Dib suggests).

The reason is that in non-python languages, spaces (as a rule) do not make sense to the compiler , but this is for people.

So,

 with myGrid do for currRow := FixedRows to RowCount - 1 do if RowChanged(currRow) then Log(currRow); if not(RecordExists(currRow)) then InsertNewRecord(currRow) else UpdateExistingRecord(currRow); 

seems to be doing something, but doing something completely different.

I would exclude end-of-line comments. Use an IDE that allocates blocks. I think Castalia will do it for Delphi. How often do you read code prints?