Correct Identation/Contex can solve the too many compiler error messages problem when a closing brac

[Roedy Green]

Visual Studio has been able to find corresponding brackets for many years.

this is a tool for finding the bug, but it won't instantly point
somewhere and say "}" should go in here, or this { should be removed.

 

[Roedy Green]

When you write an open bracket, immediately write the closing one. Then
write the code between them, and you won't forget anything. This is what
I always do and I've nevere left out a bracket.

You never copied some code and pasted it?

 

[Roedy Green]

/*first step. I want to remove the while block*/
if(xx){
adssafdsg;
asfgdggd;
afdsgsg;
for(yy){
gfsdfgh;
asdfdfd;
while(zz){
addfsdfdsf;
addfsdfdsf;
addfsdfdsf;
addfsdfdsf;
addfsdfdsf;
}
}
}

If you remove code, it is pretty easy to add one extra or drop one }
from your selection.

Recall that is real life the begin and end are often on different
screens.

 

[Ben Pfaff]

When you write an open bracket, immediately write the closing one. Then
write the code between them, and you won't forget anything. This is what
I always do and I've nevere left out a bracket.

I use an editor macro that inserts both braces at once and places
the cursor between them.

 

[DevarajA]

Roedy Green ha scritto:

You never copied some code and pasted it?

Yes, but before pasting I insert a lot of new lines to keep the new code
far from the old one. Then I check for extra brackets. It works almost
everytime, but IMHO there's no method to completely avoid those errors.

 

[Gordon Beaton]

[ newsgroups line trimmed ]

You never copied some code and pasted it?

Emacs formats my code automatically. If brackets (or braces,
parentheses, quotes or other similar tokens) no longer match properly
after a paste, the code below the format changes "shape" in a way that
is easy to diagnose.

/gordon

 

[Thad Smith]

Here is an example of the "dumb" style in action:

Can you tell where the missing closing bracket is ?

{
xxxxxxxxxxxxx{
xxxxxxxxxxxxxxxxxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxxxxxxxxxxxx{
xxxxxxxx}xxxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxxxxx{
xxxxxxxxxxxxxxxxxxxxxxxxx{
xxxxxxxx}
xxxx}
}

This is the wrong way to view a layout for K&R indentation style. The
closing brace lines up with the first non-whitespace character of the
line containing the opening brace. The essential visual information
you omitted is the distinction between leading spaces and code.
Reformatting to show this (where .... is whitespace and xxxx is code):

{ 1
.....xxxxxxxxx{ 2
.........xxxxxxxxxxxx{ 3
.........} 4
.........xxxxxxxxxxxxxxxxxxxxxxx{ 5
.........}xxxxxx{ 6
.........} 7
.........xxxxxxxxxxxxxx{ 8
.............xxxxxxxxxxxxxxxxx{ 9
.........} 10
.....} 11
} 12

Now it is easy to see that line 9 does not have a closing brace.

Thad

 

[alanglloyd]

Identifying the closing identifier of a block is a perennial problem.
As blocks are invariably used with specifying or conditional statements
I always add the conditional or specifying statement as a comment to
the other end of a block.

I also have an idiosyncratic (to some other) layout of begin / end
following a conditional. As the conditional node is important in
reading code (not the block id) I place the begin immediately following
the conditional on the same line. ...

with Users.CurrentUser do begin
SaveUsersSetting := (FlashWindow xor ToolsPSMSMActiveMenu.Checked)
or (Blocked xor
ToolsPSMPressPressMenu.Checked);
FlashWindow := ToolsPSMSMActiveMenu.Checked;
Blocked := ToolsPSMPressPressMenu.Checked;
if SaveUsersSetting then
Users.SaveToFile('');
end; {with Users.CurrentUser} // <<< commented other end

The mutiple ends of a complex block become (for example) ...

...
end; {try / finally}
end; {with TLexClients.Create(TLexClient)}
end; {if (TTimer(Sender).Tag > 0) else}

Where the block does not require a begin / end I include the "end;" in
the comment ...

with SecCmbBox do begin
{check that secservices are valid}
for i := Items.Count - 1 downto 0 do
if (DWord(Items.Objects) and PoolDWdFlag) = 0 then begin
{item is a secretary - check name for validity}
if Users.IdfromName(Items) < 0 then
Items.Delete(i);
end
else
{item is a pool - check name for validity}
if Pools.IdFromName(Items) < 0 then
Items.Delete(i);
{end; if (DWord(Items.Objects) and PoolDWdFlag) > 0 else}
{end; for i := Count - 1 downto 0 do}
end; {with SecCmbBox}

Note the indented "end" before an "else". The "else" is the node in the
program flow, not the "end", so the "else" should be more apparent than
the "end".

When one comes to modify the code, place an empty line with some marker
at the beginning and the end of the block, then modify and re-blockid
the marked section. then remove the markers.

I'm sure others will disagree vehemently with this. I have reasons for
my arrangement. I and others find it easy to read, I rarely get excess
begin / ends. It works for me.

Alan Lloyd

 

[Richard Bos]

["Followup-To:" header set to comp.lang.java.programmer.]
On 2005-09-09, Skybuck Flying penned:

[ ...something irrelevant ]

Are you a troll? You look like one.

Eh. Said individual has been proving himself either a troll, or a rather
stubborn and varied kook, for several years now.

Richard

 

[Oliver Wong]

DevarajA, your advice about always putting the closing bracket when you
put an opening bracket is an excellent one, and one that I've been following
myself. Incidentally, if you use the Eclipse IDE, it will automatically put
the closing bracket for you.

Right now I realized that if you have many nested blocks it could be hard
to tell where the one to delete ends. In this case you can count the open
brackets and subtract one each close bracket you encounter. The close
bracket taking you to '0' is the last one. Hit del.

In Eclipse, Visual Studio, and probably many other IDEs, you can put
your cursor on the opening bracket of the block you want to delete, and the
IDE will highlight the corresponding closing bracket, so you don't even need
to do this counting manually.

- Oliver

 

[Alan Balmer]

this is a tool for finding the bug, but it won't instantly point
somewhere and say "}" should go in here, or this { should be removed.

Thankfully.

As for reformatting, Slickedit does a fair job. As for finding
matching braces, even vi can do that.

 

[Alan Balmer]

When you write an open bracket, immediately write the closing one. Then
write the code between them, and you won't forget anything. This is what
I always do and I've nevere left out a bracket.

Long ago, I programmed Slickedit to produce a right bracket every time
I typed a left bracket.

 

[Alan Balmer]

DevarajA, your advice about always putting the closing bracket when you
put an opening bracket is an excellent one, and one that I've been following
myself. Incidentally, if you use the Eclipse IDE, it will automatically put
the closing bracket for you.



In Eclipse, Visual Studio, and probably many other IDEs, you can put
your cursor on the opening bracket of the block you want to delete, and the
IDE will highlight the corresponding closing bracket, so you don't even need
to do this counting manually.

Slickedit can be asked to highlight the entire block, and the delete
key does the rest.

 

[Bruce Roberts]

The point that I was making is that a computer/compiler can use the
"indentation" (tab characters or spaces) to identify where a statement block
has ended. Thus it can also detect in which statement block a bracket is
missing.

However this creates an interesting possibility. Instead of using "begin"
and "end" or "{" and "}" to indicate the start and end of a statement
block, the indentication itself could also be used to identify the start end
end of a statement block.

Unfortunately this locks authors into one particular layout. There are
almost as many different styles of writing Pascal / Delphi as there are
authors. Personally I know that I have more difficultly understanding code
written in styles that are significantly different from my own. This doesn't
mean that these styles, or my own, are poor, just different.

BTW Begin / End do not mark the start and end of a statement. They are a
statement. As is For / Do, If / Then [/ Else], With / Do, Repeat / Until,
While / Do, Case / End, etc.

I also wonder how one handles situations where an expression is too long to
comfortably fit on a single line. Does it mean that one now has to add a
line continuation marker to the language, a la VB? If so, YUK.

 

[Bruce Roberts]

I have proven that one style is cumbersome and therefore dumb and one style
is handy and therefore smart.

Debatable. What you have really proven is that you do not understand the
grammar.

 

[Alan Balmer]

It was easy to see because all the distracting clutter of the program
itself was stripped away. That hints at a possible tool for helping
find the bugs.

Please note the end of my reply. It's not wise to trust the layout to
define blocks, unless you're writing Python.

The original request was that something AUTOMATICALLY find and correct
or prevent mismatch errors.

I don't think automatic correction is possible, since a matching
bracket could be inserted anywhere. The logic of the program would
change, probably dramatically, but it would be syntactically correct.

Count up the total hours you have wasted in your life chasing such
bugs. Surely a machine should be able to do this better than you will
a little tinkering to the IDE or the language.

Very few hours, and never in my own code. Such bugs are easily
prevented by always typing the closing bracket at the same time as the
opening bracket. With many (most?) editors, this can be automated.

If such bugs are present, most editors that I've used have a way of
matching brackets, which can be a great help.

If you enjoy this sort of work, perhaps you also enjoy collecting
rubber bands and rolling them into balls. Go ahead, but please don't
try to block those of us who find such work mind-numbing, pointless
and infuriating.

I'm not sure what brought on that particular bit of invective. I find
it much better to prevent the need for such work, than to dream about
a program which can magically guess what I meant to write.

 

[David Harper]

This is reminding me of a programming language I used 20 years ago named
Promal. It was a C/Pascal-like language that used indentation to show how
code is nested, instead of using begin-end or {}. It was available for
MS-DOS, Apple-II and the Commodore 64.

- David Harper

 

[Skybuck Flying]

I did, I just don't agree with your premise.

No, you didnt read or understand it well enough.

The choice of '{}', 'begin end', ';', and any other language block
scoping identifiers is irrelevant - they all suffer the same problems of
people not aligning them.

I agree the choice of {} begin/end etc is irrelevant.

The aligning is most relevant.

The pascal style aligns it properly vertically like so:

if a<b then
begin

end;

Some C styles dont align like so:

if (A<b) {

}

Making it harder to spot where the brackets start and end in an eye's blink
like shown in previous examples.

Again you didnt read it well enough or didnt understand it

You may find the words 'begin & end' to be easier to read and thats fine
- others find them cumbersome.

No you dont understand.

 

[Skybuck Flying]

Debatable.

You can debate it all you want. Tests however will prove that one style is
fast at finding missing brackets and the other style is slow at it

What you have really proven is that you do not understand the
grammar.

I don't feel there is anything wrong with it lol... but that's just me being
used to the dutch grammar.

I guess the correct english grammar could be:

I proofed... etc. instead of I have proven.

The difference could be something like this:

I proofed.... meaning: I did something

I have proven meaning: I own my own actions, I have done that... etc

Bye,
Skybuck.

 

[Skybuck Flying]

Please note the end of my reply. It's not wise to trust the layout to
define blocks, unless you're writing Python.

The original request was about preventing compilers from generating enormous
ammounts of error messages as soon as a bracket is missing. For example by
programming mistake or accident.

The compiler could do this by looking at the indentation which if used
consistently indicates where a statement block starts and stops.

So at the end of a statement block there should be a closing bracket... if
there isn't the compiler could simply stop right there instead of looking at
the rest of the code etc and generating invalid/crazy/stupid error messages


Bye,
Skybuck.