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

[Irrwahn Grausewitz]

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

[250+ cross posted lines about source code indentation styles snipped]

1. Wow, it's nothing at all to do with the C language.

2. No-one else ever noticed the benefits of a consistent indentation
scheme. You're actually a genius.
( http://thedailywtf.com/forums/42039/ShowPost.aspx )

3. Brillant. ( http://thedailywtf.com/forums/40043/ShowPost.aspx )

F'up-To set to a.d.n.
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc frequent answers: http://benpfaff.org/writings/clc.

[Duncan McNiven]

On Fri, 9 Sep 2005 16:45:10 +0200, "Skybuck Flying"
<no****@hotmail.com> wrote:

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.

--
Duncan

[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

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

{
{

[Tim Rentsch]

[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{
xxxxxxxxxxxxxxxxxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxxxxxxxxxxxx{
xxxxxxxx}xxxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxxxxx{
xxxxxxxxxxxxxxxxxxxxxxxxx{
xxxxxxxx}
xxxx}
}

You gotta love a strawman argument.

The actual code would look like this:

{
xxxxxxxxx{
xxxxxxxxxxxx{
}
xxxxxxxxxxxxxxxxx{
}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...

[Alan Balmer]

On Fri, 9 Sep 2005 20:06:57 +0200, "Heinrich Wolf"
<in*****@invalid.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

[Skybuck Flying]

"Duncan McNiven" <sp******@teamvavavoom.co.uk> wrote in message
news:g6********************************@4ax.com...

On Fri, 9 Sep 2005 16:45:10 +0200, "Skybuck Flying"
<no****@hotmail.com> wrote:

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.

[Skybuck Flying]

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

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.

[Roberto Waltman]

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

[Roedy Green]

On Fri, 9 Sep 2005 16:45:10 +0200, "Skybuck Flying"
<no****@hotmail.com> wrote or quoted :

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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

[cs]

On Fri, 9, "Heinrich Wolf" <in*****@invalid.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****@rwaltman.net> wrote in message
news:4n********************************@4ax.com...

"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**@andrewcdonagh.f2s.com> wrote in message
news:df**********@news.freedom2surf.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*****@invalid.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.caltech.edu> wrote in message
news:kf*************@alumnus.caltech.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{
xxxxxxxxxxxxxxxxxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxxxxxxxxxxxx{
xxxxxxxx}xxxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxxxxx{
xxxxxxxxxxxxxxxxxxxxxxxxx{
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{
}
xxxxxxxxxxxxxxxxx{
}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{
xxxxxxxxxxxxxxxxxxx
xxxxxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxx{
xxxxxxxx}xxxxx
xxxxxxxx{
xxxxxxxx}
xxxxxxxxxxxxxxxxx
xxxx{
xxxxxxxxxxxxxxxxxxxxxxxx
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.

[Joan]

"Roedy Green" <lo*****@mindprod.com.invalid> wrote in message
news:su********************************@4ax.com...

On Fri, 9 Sep 2005 16:45:10 +0200, "Skybuck Flying"
<no****@hotmail.com> wrote or quoted :

Why can't a compiler do this ? Why does a compiler have to
produce so many
error messages when a closing bracket is missing ?

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

[jussij]

Heinrich Wolf wrote:

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

Skybuck wrote:
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

[jacob navia]

Skybuck Flying wrote:

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 ?

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

[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

[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

[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

[James Dow Allen]

Lately I miss a lot of braces, but they never take me
long to find. I just use the vi '%' command which matches
brace to brace (or bracket to bracket, etc.) Very easy.

Sometimes this leads to funny comments in my code:
printf( /* ( help vi % */ "Step %d)\n", stepno);

James

[cs]

On Fri, 09 Sep 2005 20:48:11 GMT, cs <n@ss.g> wrote:

On Fri, 9, "Heinrich Wolf" <in*****@invalid.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

{
compiler see this is not closed
.
.
{
{
}
}

{

^

this is not closed

.
.
.
}
is closed here
}
Which Bracket is missing? :->

Regards
Heiner

[Richard Heathfield]

James Dow Allen said:

Lately I miss a lot of braces, but they never take me
long to find. I just use the vi '%' command which matches
brace to brace (or bracket to bracket, etc.) Very easy.

Sometimes this leads to funny comments in my code:
printf( /* ( help vi % */ "Step %d)\n", stepno);

Another way to "help vi" which doesn't seem quite so funny at first is:

#define HOZE_LEFT_PAREN '('
#define HOZE_RIGHT_PAREN ')'

printf("Step %d%c\n", stepno, HV_RIGHT_PAREN);

On reflection, I am not sure which is worse. :-)
In case you're wondering... HOZE == Help Over-Zealous Editors
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/2005
http://www.cpax.org.uk
email: rjh at above domain

[Andrew McDonagh]

Skybuck Flying wrote:

"Andrew McDonagh" <ne**@andrewcdonagh.f2s.com> wrote in message
news:df**********@news.freedom2surf.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.

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.

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.

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...e+Search&meta=
Can you name any modern IDE which has the claimed feature ?
Eclipse, IntelliJ, jbuilder and more.....

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.

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

[cs]

On Sat, 10 Sep 2005 08:31:40 GMT, cs <n@ss.g> wrote:

On Fri, 09 Sep 2005 20:48:11 GMT, cs <n@ss.g> wrote:

On Fri, 9, "Heinrich Wolf" <in*****@invalid.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 is not closed
{
.
.
.
{
{
}
}
.
.
.
}^^^^^^^^^^^
this seems ok

{
compiler see this is not closed
.
.
{
{
}
}

{

^

this is not closed

.
.
.
}
is closed here
}

is closed hereWhich Bracket is missing? :->

Regards
Heiner

[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.
--
Devaraja (Xdevaraja87^gmail^c0mX)
Linux Registerd User #338167
http://counter.li.org

[Andrew McDonagh]

DevarajA wrote:

Skybuck Flying ha scritto:
[cut]

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.

[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

[DevarajA]

Heinrich Wolf ha scritto:

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.

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.

--
Devaraja (Xdevaraja87^gmail^c0mX)
Linux Registerd User #338167
http://counter.li.org

[DevarajA]

DevarajA ha scritto:

Heinrich Wolf ha scritto:

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.

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.

--
Devaraja (Xdevaraja87^gmail^c0mX)
Linux Registerd User #338167
http://counter.li.org

[Roedy Green]

On Fri, 09 Sep 2005 12:31:41 -0700, Alan Balmer <al******@att.net>
wrote or quoted :

/* } 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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

[Roedy Green]

On Sat, 10 Sep 2005 00:10:53 -0500, "Joan" <Jo**@nospam.invalid> wrote
or quoted :

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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

[Roedy Green]

On Fri, 09 Sep 2005 22:32:30 +0100, Andrew McDonagh
<ne**@andrewcdonagh.f2s.com> wrote or quoted :

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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

[Roedy Green]

On Sat, 10 Sep 2005 10:10:54 +0200, "Heinrich Wolf"
<in*****@invalid.invalid> wrote or quoted :

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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

[Roedy Green]

On Sat, 10 Sep 2005 14:42:07 GMT, DevarajA <[e-mail]> wrote or
quoted :

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?
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

[Roedy Green]

On Sat, 10 Sep 2005 15:19:21 GMT, DevarajA <[e-mail]> wrote or
quoted :

/*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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

[Ben Pfaff]

DevarajA <[e-mail]> writes:

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.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[DevarajA]

Roedy Green ha scritto:

On Sat, 10 Sep 2005 14:42:07 GMT, DevarajA <[e-mail]> wrote or
quoted :

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?

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.

--
Devaraja (Xdevaraja87^gmail^c0mX)
Linux Registerd User #338167
http://counter.li.org

[Thad Smith]

Skybuck Flying wrote:

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[i]) and PoolDWdFlag) = 0 then begin
{item is a secretary - check name for validity}
if Users.IdfromName(Items[i]) < 0 then
Items.Delete(i);
end
else
{item is a pool - check name for validity}
if Pools.IdFromName(Items[i]) < 0 then
Items.Delete(i);
{end; if (DWord(Items.Objects[i]) 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

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

"DevarajA" <[e-mail]> wrote in message
news:rV*********************@news4.tin.it...

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]

On Sat, 10 Sep 2005 23:33:10 GMT, Roedy Green
<lo*****@mindprod.com.invalid> wrote:

On Sat, 10 Sep 2005 10:10:54 +0200, "Heinrich Wolf"
<in*****@invalid.invalid> wrote or quoted :

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.

Thankfully.

As for reformatting, Slickedit does a fair job. As for finding
matching braces, even vi can do that.
--
Al Balmer
Balmer Consulting
re************************@att.net

[Alan Balmer]

On Sat, 10 Sep 2005 14:42:07 GMT, DevarajA <[e-mail]> wrote:

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.
--
Al Balmer
Balmer Consulting
re************************@att.net

[Alan Balmer]

On Mon, 12 Sep 2005 15:44:19 GMT, "Oliver Wong" <ow***@castortech.com>
wrote:

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.

"DevarajA" <[e-mail]> wrote in message
news:rV*********************@news4.tin.it...

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.

Slickedit can be asked to highlight the entire block, and the delete
key does the rest.
--
Al Balmer
Balmer Consulting
re************************@att.net