Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.

[Skybuck Flying]

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>cod e
<identation>i f a<b then
<identation>beg in
<identation><id entation>code
<identation><id entation>code
<identation>end ;
end;

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

{
<identation>cod e
<identation>i f a<b {
<identation><id entation>code
<identation><id entation>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{
xxxxxxxxxxxxxxx xxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxx xxxxxxxxxx{
xxxxxxxx}xxxxxx {
xxxxxxxx}
xxxxxxxxxxxxxxx xxx{
xxxxxxxxxxxxxxx xxxxxxxxxx{
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{
xxxxxxxxxxxxxxx xxxx
xxxxxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxx xxxxxxxxx
xxxxxxxx{
xxxxxxxx}xxxxx
xxxxxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxx xx
xxxx{
xxxxxxxxxxxxxxx xxxxxxxxx
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.

The compiler works like an autistic person. The compiler doesn't recgonize
the context and only looks at the opening and closing brackets.

The compiler could be made more smart like us who use the smart style by
looking at the context. Even the more complex style (the dumb style) could
be used to figure out where a closing bracket should have been... since even
in the dumb style the closing brackets are located at the same positions as
in the smart style.

This shows you how important correct identation is. I myself requested
automatic identation on-the-fly simply because that would be much more
productive, especially when code needs to be cut and pasted in some other
section. In those cases the identation has to be changed everywhere in the
pasted code and it would be really handy if that was automatically done.

However automatic identation can conflict with the solution above. Automatic
identation depending on it's implementation could start moving the
brackets/identations back and forth when a bracket is accidently deleted,
thereby possibly cancelling the usefull information in the
context/identation. Solving this secondary problem remains a challenge for
now ;) =D(ofcourse it's not such a big problem in pascal/delphi since it's
impossible to delete begin/end with a single touch of a button, since it's a
multiple character word ;) unless
it somehow gets cut/deleted away :) )

And in case you were wondering what the real code was here it is:

"dumb style version":

{
if (a<b) {
if (sdfd<c) {
}
if (sqfd<342563) {
} else {
}
}

if (dddd=234) {
if (dsdfssdf=23) {
}
}
}

"smart style version":

{
if (a<b)
{
if (sdfd<c)
{
}
if (sqfd<342563)
{
} else
{
}
}

if (dddd=234)
{
if (dsdfssdf=23)
{
}
}
}

And here is how any other revealing arbitrary code/information was replaced
by x's to soley focus on the identation and brackets themselfes as to see
how easy or hard it would be to recognize where a bracket was missing in an
eye's blink ;) (the 9th bracket below is still present for completeness
sake.)

(Fixed character width font needed for easy viewing of the text below, like
courrier.)

"the dumb style:"

{
if (a<b) {
xxxxxxxxxxxxx{
if (sdfd<c) {
xxxxxxxxxxxxxxx xxxxx{
}
xxxxxxxx}
if (sqfd<342563) {
xxxxxxxxxxxxxxx xxxxxxxxxx{
} else {
xxxxxxxx}xxxxxx {
}
xxxxxxxx}
}
xxxx}
if (dddd=234) {
xxxxxxxxxxxxxxx xxx{
if (dsdfssdf=23) {
xxxxxxxxxxxxxxx xxxxxxxxxx{
}
xxxxxxxx}
}
xxxx}
}

"the smart style":

{
if (a<b)
xxxxxxxxxxxx
{
xxxx{
if (sdfd<c)
xxxxxxxxxxxxxxx xxxx
{
xxxxxxxx{
}
xxxxxxxx}
if (sqfd<342563)
xxxxxxxxxxxxxxx xxxxxxxxx
{
xxxxxxxx{
} else
xxxxxxxx}xxxxx
{
xxxxxxxx{
}
xxxxxxxx}
}
xxxx}
if (dddd=234)
xxxxxxxxxxxxxxx xx
{
xxxx{
if (dsdfssdf=23)
xxxxxxxxxxxxxxx xxxxxxxxx
{
xxxxxxxx{
}
xxxxxxxx}
}
xxxx}
}

Bye,
Skybuck.

[Alan Balmer]

On Fri, 9 Sep 2005 20:06:57 +0200, "Heinrich Wolf"
<in*****@invali d.invalid> wrote:

Hi,

Indentation will not give you much clarity,
when the code has nested and cascaded brackets
with the outmost ones very far from each other.

{
{
.
.
.
{
{
}
}
.
.
.
}
{
.
.
{
{
}
}
{
.
.
. /* } probably this one, but you have to check the logic of the
program to be sure. The pattern is quite easy to see - what was your
point? */ }
}
Which Bracket is missing? :->

Regards
Heiner

--
Al Balmer
Balmer Consulting
re************* ***********@att .net

[cs]

On Fri, 9, "Heinrich Wolf" <in*****@invali d.invalid> wrote:

Hi,
Indentation will not give you much clarity,
when the code has nested and cascaded brackets
with the outmost ones very far from each other.
{
{
.
.
.
{
{
}
}
.
.
.
} ^^^^^^^^^^^
this seems ok
{
.
.
{
{
}
} {
^

this is not closed
.
.
.
}
}
Which Bracket is missing? :->

Regards
Heiner

[Skybuck Flying]

"Roberto Waltman" <us****@rwaltma n.net> wrote in message
news:4n******** *************** *********@4ax.c om...

"Skybuck Flying" <no****@hotmail .com> wrote:

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 endend of a statement block.

For example:

Something1;

if (a<b)
Something3;
Something4;

Something6;

Possibility exploited already by languages such as Occam & Python, may
be others.

Thanks,

Good to know that, otherwise I start wondering why nobody else thought of it
or used it etc...

Bye,
Skybuck.

[Monique Y. Mudama]

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

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.

The compiler works like an autistic person. The compiler doesn't
recgonize the context and only looks at the opening and closing
brackets.

Have you looked at Python? Python actually uses the whitespace
itself, no brackets.

I don't think the compiler should be dependent on coding style. And I
still like my brackets nestled up against the right paren, dammit!

--
monique

Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

[Monique Y. Mudama]

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

Hi,

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.

Vim supports this. The feature is called 'folding'.

--
monique

Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

[Monique Y. Mudama]

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

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

You have failed to produce any reasoning, prove or examples of the
opposite.

There is a difference between providing arguments and being stubern.
Are you a troll? You look like one.

No you cannot easily re-format the code with a formatting utility
simply because there isn't a single formatting utility in the world
that supports all different coding styles.

http://www.jindent.com/

--
monique

Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

[Andrew McDonagh]

Skybuck Flying wrote:

Sometime ago on the comp.lang.c, I saw a teacher's post asking why C

snipped very long message about badly written code and how to 'fix' it
by making indentation better....
You are missing the point....

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.

Second any method/procedure which is so long that its hard to see the
logical parts of it, is too long....making smaller will help in numerous
ways, not least making it easier to see the indent problems.

[Skybuck Flying]

"Andrew McDonagh" <ne**@andrewcdo nagh.f2s.com> wrote in message
news:df******** **@news.freedom 2surf.net...

Skybuck Flying wrote:

Sometime ago on the comp.lang.c, I saw a teacher's post asking why C

snipped very long message about badly written code and how to 'fix' it
by making indentation better....
You are missing the point....
No, I think you didn't read my post well enough.

Here are the main points:

Point 1: With the pascal style bracketing/layout it is easier to spot
missing brackets.
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. )
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.
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 ?
Does visual studio .net 2003 have such a code formatting option ?
Does borland delphi 7 have such a code formatting option ?

Can you name any modern IDE which has the claimed feature ?
Second any method/procedure which is so long that its hard to see the
logical parts of it, is too long....making smaller will help in numerous
ways, not least making it easier to see the indent problems.

Point 2 does this automatically for you.
Point 1 helps you narrow it down.

Bye,
Skybuck.

[Skybuck Flying]

"Heinrich Wolf" <in*****@invali d.invalid> wrote in message
news:3o******** ****@individual .net...

Hi,

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.

Ok, so what do you suggest we do ?

Do you suggest we start collapsing all statement blocks to find any missing
brackets before we click the compile button as to prevent the storm of error
messages if we do have a missing bracket ?

Bye,
Skybuck.

[Skybuck Flying]

"Tim Rentsch" <tx*@alumnus.ca ltech.edu> wrote in message
news:kf******** *****@alumnus.c altech.edu...

[newsgroups trimmed to comp.lang.c only]

"Skybuck Flying" <no****@hotmail .com> writes:

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. [...snip...blah. blah.blah...]

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

Can you tell where the missing closing bracket is ?

{
xxxxxxxxxxxxx{
xxxxxxxxxxxxxxx xxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxx xxxxxxxxxx{
xxxxxxxx}xxxxxx {
xxxxxxxx}
xxxxxxxxxxxxxxx xxx{
xxxxxxxxxxxxxxx xxxxxxxxxx{
xxxxxxxx}
xxxx}
}

You gotta love a strawman argument.

You make it seem like a strawman argument, since you only converted one
example.

The actual code would look like this:

{
xxxxxxxxx{
xxxxxxxxxxxx{
}
xxxxxxxxxxxxxxx xx{
}xxxxxx{
}
xxxxxxxxxx{
xxxxxxxxxxxxx{
}
}
}

Only a moron couldn't see where the missing brace (aka "bracket")
should go in well under 30 seconds (and that's being generous).

Or perhaps someone who learned programming in Delphi...

Shall we keep things fair and convert the other example as well ?

Smart style:

{
xxxxxxxxxxxx
xxxx{
xxxxxxxxxxxxxxx xxxx
xxxxxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxx xxxxxxxxx
xxxxxxxx{
xxxxxxxx}xxxxx
xxxxxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxx xx
xxxx{
xxxxxxxxxxxxxxx xxxxxxxxx
xxxxxxxx{
xxxxxxxx}
xxxx}
}

I shall quote you and modify it:

"Only a moron couldn't see where the missing brace (aka "bracket")
should go in well under 5 seconds (and that's being generous)."

As you can see the end result remains the same, the smart style beats the
dumb style.

You are quite the moron yourself there ;)

Bye,
Skybuck.