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

J

Joan

<snip>

I think the original motivation came from the IBM/CDC Batch
world.
This is where you submit your card deck and wait. If the compiler
stops at the first little error, you don't get any feedback on
the rest of
your source, which leads to excessive delays.
 
C

Chris Head

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Skybuck Flying wrote:
[snip]
Adept ! Resistence is futile ! =D
[snip]

Greetings,
Not to be picky, but I guess you meant adapt (though I would say that
judging by her post history Monique is an "adept" programmer too...)

Anyway, I believe that for a competent programmer, it shouldn't be much
more difficult to look down a column and check that every "if", "while",
"do", "for", "switch", method, class, and so on has a matching
close-brace. I find it perfectly easy, myself, anyway. Instead of seeing
{ and looking for }, I see "if" and look for }. This obviously requires
that you always put braces around the bodies of control structures, but
I think anyone who doesn't should be shot. That's just my opinion.

The point is, it's easy to see which line should be the opening and
which line should be the closing because between them you should have
only whitespace in that column. Then you can simply make sure the brace
closes where it should. Using your style of examples, it's more like this:

XXXXif () {
XXXXXXXXfoo();
XXXXXXXXbar();
XXXX}

Note how between the if line and the } line there are only Xs,
so the structure is easy to see (even easier if they were blanks instead
of Xs). An error would look like this:

XXXXif() {
XXXXXXXXfoo();
XXXXXXXXbar();
XXXXbaz();

A quick check will immediately show that there's a block of whitespace
in column 5 which is NOT followed vertically by a } character.

I believe your examples were intentionally harder to follow than real
code because you did not show the control structure commands starting
the individual blocks as very visually different from the blank space,
which in real life they are. You pretended they blended in with the
blank space, and only showed the braces.

Of course, to each his/her/its (?) own.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFDIn1c6ZGQ8LKA8nwRAkHDAKCuTinP3h9H2GNwZNErS+xQEJH+pwCfRUQx
5GyLiIi6WMZzXfua+9wEZlY=
=M/Mo
-----END PGP SIGNATURE-----
 
J

jussij

Heinrich said:
some time ago I have seen an editor, which can collapse
the Lines between corresponding brackets. If you use such
an editor, you will quickly find out, which bracket is
missing.

Zeus is just such an editor:

http://www.zeusedit.com/lookmain.html
Note: Zeus is shareware
Can you tell where the missing closing bracket is ?

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

As a test I loaded this snippet of code into a test.cpp
file and sure enough the code folding quickly identified
the missing bracket.

Jussi Jumppanen
Home Page: http://www.zeusedit.com
 
J

jacob navia

Skybuck said:
I dont know about that maybe I am missing some points or maybe you making
this up.

Some questions:

Does borland delphi 2005 have such a code formatting option ?
It has so many bugs and crashes so often, but anyway.
I asked in the support group for that IDE if there was an option
to match begin/end and there is NONE.
*BUT* you can tweak registry values so that the IDE will match
begin/ends most of the time, but only with regular expressions
what doesn't work most of the time.
Does visual studio .net 2003 have such a code formatting option ?
No.

Does borland delphi 7 have such a code formatting option ?
NO.

Can you name any modern IDE which has the claimed feature ?
YES!!!
http://www.cs.virginia.edu/~lcc-win32
In the main menu:

EDIT --> Reformat.

Besides lcc-win32 will WARN you when any mismatched brackets occur
and will tell you which bracket is too much or too
many!!!
 
H

Heinrich Wolf

Hi,

since this is also in a delphi newsgroup,
I replace brackets by begin and end.

After coding let first the compiler do its work.

If it complains about an end too much,
normally it is just at the indicated line.
Otherwise start to collapse towards the top.

If the compiler is totally confused, I guess, an end is missing
and I start to collapse towards the end.

Indenting may be an additional help,
but this also may have been formatted wrong.
What counts to the Delphi compiler, is begin and end,
and an appropriate editor can find for you
the correspondinge ones.

Has anyone here seen the Gupta / Century Team Developer
(4GL Compiler)?
It comes with its proprietary language and its proprietary editor.
It's similar to Delphi in RAD,
has many bugs in syntax checking and so on,
but it's designed for and very powerful in SQL,
eg. it has tables populated with combo-box-
and check-box-columns.
This language has neither brackets,
nor other keywords like begin end for building blocks.
Indenting is a property of the language!
The editor collapses blocks at the same indentation level.

Regards
Heiner
 
H

Heinrich Wolf

Hi,

there is an editor with syntax plug-ins
for several languages, e.g. C
called Diamond X32.
A diagram covers all the program flow control.
A straight forward block is inserted in the native language.

Example:
Format the following text
to fixed character width
and replace the dots by blanks.
+---------------------------------------+
|if.(x.<.5).............................|
+then-------+else-----------------------+
|puts("ok");|for.(i.=.1;.i.<.10;.i.++)..|
|ok.=.true;.|..+------------------------+
|...........|..|printf("%d\n",.i);......|
+-----------+--+------------------------+

Regard
Heiner
 
H

Heinrich Wolf

Are you a troll? You look like one.

He is!
But he is one who can start to make things change,
where it's necessary.

Regards
Heiner
 
H

Heinrich Wolf

Does visual studio .net 2003 have such a code formatting option ?
Visual Studio has been able to find corresponding brackets for many years.
AFAIK Visual Studio .net can collapse the block in corresponding brackets
Does borland delphi 7 have such a code formatting option ?

Can you name any modern IDE which has the claimed feature ?
Try Diamond X32 or Centura / Gupta Team Developer

I don't find it a good idea to make a compiler
suggest corrections based on the indentation,
as long as the language itself does not care about indentation at all.

Bye
Heiner
 
A

Andrew McDonagh

Skybuck said:
No, I think you didn't read my post well enough.

I did, I just don't agree with your premise.
Here are the main points:

Point 1: With the pascal style bracketing/layout it is easier to spot
missing brackets.

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.

You may find the words 'begin & end' to be easier to read and thats fine
- others find them cumbersome.
Point 2: Indentation can be used by the computer/compiler to spot missing
brackets.
(It can figure out where statement blocks start and stop and where missing
brackets are and can simply stop the flow of error messages. )

In some languages yes, but not all languages could.
I dont know about that maybe I am missing some points or maybe you making
this up.

Not making anything up...
Some questions:

Does borland delphi 2005 have such a code formatting option ?
Does visual studio .net 2003 have such a code formatting option ?
Does borland delphi 7 have such a code formatting option ?


I'm not sure about Delphi 2005 or VS2005 as haven't seen them...but let
me google it...hang on in there... I can't find much info about VS or
Delphi 2005 and Delphi 7 and earlier does not natively support
formatting, but there are plenty of add-ons...

http://www.google.co.uk/search?hl=en&q=delphi+7+code+formatting&btnG=Google+Search&meta=


Can you name any modern IDE which has the claimed feature ?

Eclipse, IntelliJ, jbuilder and more.....
Point 2 does this automatically for you.
Point 1 helps you narrow it down.

True they would help with the symptom, but the cure would be not to
create such long methods/procedures which cause mismatching blocks in
the first place.

The smaller a method the easier to read and see, add in code formatters
and the problem 'justGoesAway'
Bye,
Skybuck.

cheerio

Andrew
 
D

DevarajA

Skybuck Flying ha scritto:
Sometime ago on the comp.lang.c, I saw a teacher's post asking why C
compilers produce so many error messages as soon as a closing bracket is
missing. The response was simply because the compiler can't tell where a
bracket is missing.... a few weeks have past, I requested a feature for the
delphi ide/editor "automatic identation of code in begin/end statements etc"
and today when I woke up I suddenly released a very simple solution for this
problem by simply using something called "contex". Which is something
autistic people have great trouble recognizing and since many autistic
people work in the tech industry here is a short example to explain how
"context" can solve the problem.

Let's look at two identation styles.

The first one is my preferred style which is commonly used in pascal/delphi.
Some people in the delphi community recommended to use 2 spaces for identing
a few years ago. I do hope that they by now realize that using tabs is much
more efficient and works faster. I myself use 4 spaces for each tab
character. (Which is also used further down in this example (tabs converted
to spaces) )

Anyway let's get back to the styles.

The first style: pascal/delphi style/my style (the smart style):

begin
<identation>code
<identation>if a<b then
<identation>begin
<identation><identation>code
<identation><identation>code
<identation>end;
end;

The second style: perverted C/Java style (the dumb style):

{
<identation>code
<identation>if a<b {
<identation><identation>code
<identation><identation>code
<identation>}
}

Let's compare both styles.

The second/dumb style is much more hard to figure out where a missing
bracket is located.

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}
}

If you did manage to find it it must have costs you lot's of time to figure
it out ;) Since to figure it out a complex algorithm is necessary to find
the missing bracket.

Now I present to you the smart style:

{
xxxxxxxxxxxx
xxxx{
xxxxxxxxxxxxxxxxxxx
xxxxxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxx{
xxxxxxxx}xxxxx
xxxxxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxxxx
xxxx{
xxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxx{
xxxxxxxx}
xxxx}
}

You didn't spot it the first time ? Take a closer look ! ;)

Yeah now you see it don't you ;)

The 9th bracket is missing in both examples.

However it did cost you much less time to figure out where the missing
bracket is in the smart style.

Why can't a compiler do this ? Why does a compiler have to produce so many
error messages when a closing bracket is missing ? Why isn't the compiler
smart like us ? (well at least some of us)

The answer is: in the context. We are aware of the context.

The context is the identation. The identation indicates where a statement
block begins and ends.
[cut]

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.
 
A

Andrew McDonagh

DevarajA said:
Skybuck Flying ha scritto:

cut even more...
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.

Brilliant! Nicely stated, short and straight to the point example of how
'we' can solve our problems rather than rely upon tools.
 
H

Heinrich Wolf

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.

Sounds very reasonable at first glance. I also do that.

But a software is only then successful,
when it is changed and improved many many times.
Brackets are not lost on initial coding, but on altering it.
God beware that you delete a bracket
and while you think you delete the corresponding one,
you delete a different!

Bye
Heiner
 
D

DevarajA

Heinrich Wolf ha scritto:
Sounds very reasonable at first glance. I also do that.

But a software is only then successful,
when it is changed and improved many many times.
Brackets are not lost on initial coding, but on altering it.

The only case (I can think of) that requires the brackets to be removed
is when you delete the whole code of a block. In that case you can
remove the code first and then the empty brackets {}.
Look at the following c example code:

/*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;
}
}
}

/*second step. Remove only the code in the block*/
if(xx){
adssafdsg;
asfgdggd;
afdsgsg;
for(yy){
gfsdfgh;
asdfdfd;
while(zz){} /*a couple of empty brackets*/
}
}

/*third step. Remove the brackets (and while())*/
if(xx){
adssafdsg;
asfgdggd;
afdsgsg;
for(yy){
gfsdfgh;
asdfdfd;
}
}


I'm a newbie, so my solution may be quite naive and not usable in real
programming, but for my works it always worked.
 
D

DevarajA

DevarajA ha scritto:
Heinrich Wolf ha scritto:



The only case (I can think of) that requires the brackets to be removed
is when you delete the whole code of a block.

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.
 
R

Roedy Green

/* } probably this one, but you have to check the logic of the
program to

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.

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

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.

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.
 
R

Roedy Green

This is where you submit your card deck and wait. If the compiler
stops at the first little error, you don't get any feedback on
the rest of
your source, which leads to excessive delays.

I find it amazing that 50 engineers shared a computer with about the
power of an XT with less RAM. Yet the ability to frustrate of a
modern Pentium with many times the ram and cpu power is much higher.
 
R

Roedy Green

Any modern IDE has a format code option which will layout the code
regardless of your brackets - allowing you to see where the problem is.

An IDE can only show you one screen full at a time. If your problem is
with the nested class brackets you can scoot up and down over and over
and still not see it.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,774
Messages
2,569,599
Members
45,165
Latest member
JavierBrak
Top