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.
