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

S

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

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) {
xxxxxxxxxxxxxxxxxxxx{
}
xxxxxxxx}
if (sqfd<342563) {
xxxxxxxxxxxxxxxxxxxxxxxxx{
} else {
xxxxxxxx}xxxxxx{
}
xxxxxxxx}
}
xxxx}
if (dddd=234) {
xxxxxxxxxxxxxxxxxx{
if (dsdfssdf=23) {
xxxxxxxxxxxxxxxxxxxxxxxxx{
}
xxxxxxxx}
}
xxxx}
}

"the smart style":

{
if (a<b)
xxxxxxxxxxxx
{
xxxx{
if (sdfd<c)
xxxxxxxxxxxxxxxxxxx
{
xxxxxxxx{
}
xxxxxxxx}
if (sqfd<342563)
xxxxxxxxxxxxxxxxxxxxxxxx
{
xxxxxxxx{
} else
xxxxxxxx}xxxxx
{
xxxxxxxx{
}
xxxxxxxx}
}
xxxx}
if (dddd=234)
xxxxxxxxxxxxxxxxx
{
xxxx{
if (dsdfssdf=23)
xxxxxxxxxxxxxxxxxxxxxxxx
{
xxxxxxxx{
}
xxxxxxxx}
}
xxxx}
}

Bye,
Skybuck.
 
D

Duncan McNiven

On Fri, 9 Sep 2005 16:45:10 +0200, "Skybuck Flying"

Your arguement is based on the false premise that you know the one
true way to lay out code. Developer's have argued over that for
decades without reaching a concensus, and it is much more productive
to realise that

a) Different people may prefer different styles, often for very good
reasons.

b) You can easily re-format the code with a formatting utility if you
need to co-operate with someone using a different style.

c) Tabs are worse than spaces when you want to share code with others
who may use a different editor or different settings. You yourself
converted your tabs to spaces before posting here, thus proving the
point.

d) If you set smart tabs on in the Delphi editor - or the equivelant
in whatever editor you prefer - you can use the tab key to avoid
multiple presses of the space key, but spaces are inserted in your
code. For me, that is the best of both worlds. YMMV.

For me, the keyboard shortcuts for indenting / unindenting blocks of
code, plus smart tabs, mean that achieving the layout I want is easy
enough, even when I cut/paste/delete etc. On-the-fly reformatting,
such as occurs in the Visual Basic editor, is something I find truly
annoying. If you want it, fine, write it, but do realise that it won't
suit everyone.
 
H

Heinrich Wolf

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.

Regards
Heiner
 
H

Heinrich Wolf

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.

{
{
 
A

Alan Balmer

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? */
 
S

Skybuck Flying

Duncan McNiven said:
On Fri, 9 Sep 2005 16:45:10 +0200, "Skybuck Flying"

Your arguement is based on the false premise that you know the one
true way to lay out code. Developer's have argued over that for
decades without reaching a concensus, and it is much more productive
to realise that

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.
a) Different people may prefer different styles, often for very good
reasons.

Different People ? May ? Reasons ? Styles ?

Please be more specific.
b) You can easily re-format the code with a formatting utility if you
need to co-operate with someone using a different style.

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.
c) Tabs are worse than spaces when you want to share code with others
who may use a different editor or different settings. You yourself
converted your tabs to spaces before posting here, thus proving the
point.

1. No. I could not use tab characters because ms outlook express can't work
with it.

2. No. I did not use spaces because it is difficult to tell how many spaces
I created in a variable character width font. So instead I used a visible
character in this case 'x' to indicate how many "spaces" or "tabs" are
present. So that I and others can easily count them and see that all
indentation is correct.

3. No. Using tabs is better for sharing code with other people. Just because
this post does not allow it, does not mean that it would not have been
better.

Let's get some facts straight:

The purpose of a space character is to seperate.
The purpose of a tab character is to indent.

Spaces are commonly found between words. The visual width of a space can
vary from font to font.

The concept of indentation is to make sure that the start of every
indentation is vertically aligned.

And that is exactly what I wanted to achieve. I wanted to achieve vertical
alignment of all characters.

The only way I could have done that with a variable width font is to use the
tab character.

The end user can then simple set the visual width of the tab character to
the maximum possible width of a character.

So in short tab characters allow: perfect font indepedant visual vertical
alignment. That is something that spaces can never do.

As soon as people realise this the discussion/arguing/stubernness about
which method in theory is better should cease to exist.

However as with all concepts, theories and standards if it's not implemented
correctly it won't work.

And Microsoft Outlook Express is a fine example of this in action as we are
used from Microsoft.
d) If you set smart tabs on in the Delphi editor - or the equivelant
in whatever editor you prefer - you can use the tab key to avoid
multiple presses of the space key, but spaces are inserted in your
code. For me, that is the best of both worlds. YMMV.

The delphi text editor is not as good as other text editors like textpad
which allow to work much faster with tabs by simpling jumping from tab to
tab. Delphi on the other hand is slower because the cursor has to go through
the tabs like if they were spaces.
For me, the keyboard shortcuts for indenting / unindenting blocks of
code, plus smart tabs, mean that achieving the layout I want is easy
enough, even when I cut/paste/delete etc.

Still sounds cumbersome... Let me guess:

I have to first select the text which I want to indent and then press some
kind of keyboard shortcut... and ofcourse when I accidently do it wrong I
loose my code ? great.

I rather have automatic easy indenting which could be turned on/off in the
editor options as to prevent extra work or costly mistakes.
On-the-fly reformatting,
such as occurs in the Visual Basic editor, is something I find truly
annoying. If you want it, fine, write it, but do realise that it won't
suit everyone.

I don't know if I would find it annoying... I would have to try it out ;)

Bye,
Skybuck.
 
S

Skybuck Flying

Heinrich Wolf said:
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.

{
{
.
.
.
{
{
}
}
.
.
.
}
{
.
.
{
{
}
}
{
.
.
.
}
}
Which Bracket is missing? :->

A human needs to scroll down, scroll up, scroll back down etc, and finally
he will see which bracket is missing. The pascal style is still more easy
to figure out.

But this is all beside the point.

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.

For example:

Something1;
Somethng2;

if (a<b)
Something3;
Something4;
Something5;

Something6;
Something7;
Something8;

if (c<d)
Something9;
Something10;

if (e<f)
Something11;
Something12;
else
Something13;
Something14;
else

if (g<h)
Something15;
Something16;
else
Something17;
Something18;

Something19;

So the remarkable thing is that all this "start"/"stop" overhead is not even
necessary if indentation is used consistently and correctly.

Bye,
Skybuck.
 
R

Roberto Waltman

Skybuck Flying said:
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.

For example:

Something1;

if (a<b)
Something3;
Something4;

Something6;

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

Roberto Waltman

[ Please reply to the group, ]
[ return address is invalid. ]
 
R

Roedy Green

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 other reason is that the } in overused in C and Java. You need a
slightly different sort of marker for end of if, end of loop end of
method. Then the compiler has no trouble narrowing down what the
problem is.

There are a number of ways around the problem:

1. a scid inserts markers in pairs and ties them together. It knows
they are pair. When you pull one out, the other comes with it.
So you CAN'T get unbalanced.

2. When you insert the scid marks them with a flavour e.g. end of
class, end of method. That cannot change. You must remove the token
to change its flavour. It would look slightly different( differing
color, font, icon) on screen even if logically there were all ordinary
() {} [] to the compiler. This way the compiler can insert missing
markers for you in reasonably logical places, at least for the purpose
of composing error messages.
 
S

Skybuck Flying

Roberto Waltman said:
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.
 
M

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!
 
M

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'.
 
M

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

Andrew McDonagh

Skybuck said:
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.
 
S

Skybuck Flying

Monique Y. Mudama said:
["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.

Yes I did today, cool isn't it ?
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!

Adept ! Resistence is futile ! =D
 
S

Skybuck Flying

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

Skybuck Flying

Monique Y. Mudama said:
["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/

Try to think a littttttttle bit bigger than only your own java world ;)

Bye,
Skybuck =D
 
S

Skybuck Flying

Heinrich Wolf said:
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.
 

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

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,055
Latest member
SlimSparkKetoACVReview

Latest Threads

Top