Re: Java blunders
On 7/23/2014 10:23 AM, Silvio wrote:
On 07/23/2014 01:44 PM, Roedy Green wrote:
On Tue, 22 Jul 2014 21:02:07 -0500, Joshua Cranmer ?
<Pidgeot18@verizon.invalid> wrote, quoted or indirectly quoted someone
who said :
C. On the balance, I think matching curly braces is superior to
begin/end-ish constructs. If you're spending too much time trying to
figure out where you have an extra or a missing curly brace, then, quite
frankly, your IDE is defective. My IDE points out matching curly braces
and can even fold them based on appropriate matching, and it has been
able to do so since before Java was invented. Possibly since before I
was born, even.
I find sorting out braces is by far the most-time consuming busywork
in preparing Java source. It is not fun. It is just irritating.
I have a problem with IntelliJ. I want to tidy the code to help
visually sort out the brace misbalance problem. However, if I invoke
the tidier on an program of imperfect syntax, it often does horrible
violence.
I have even written some tools for balancing in pernicious cases.
http://mindprod.com/products1.html#BRACEBALANCER
http://mindprod.com/products1.html#MASMBALANCER
If you could pin down certain braces as having a given function (e.g.
end method, that will not be disturbed by a stray } or one
accidentally hidden by a //. The IDE could go right to the problem,
and suggest a fix.
In JDisplay, my program for colourising and fontifying Java source
code for display on the Internet, it use bigger braces on the outside
and smaller ones in the inside. This helps visually balance them.
I suppose with a fancier parser I could make the braces subtly
different colours, so you can more easily tell an end loop from an end
method or an end if. You might not even consciously notice it.
I could imagine an IDE of the future have set of glyphs it uses in
place of {} to tell you the function of the {} it gleaned. You just
type {} as always. You might also do things with the backgrounds to
demark blocks
Much of the pain of matching braces (both typing and proof-reading)
disappears when you change
if (IHadAHammer) {
IdHammerInTheMorning();
}
to
if (IHadABell)
{
IdRingItInTheMorning();
}
I never understood why anyone would use the former form. The Scala world
adopted the funky end-of-line opening brace from Java and the only
argument I ever got was that it is one source line less and makes deep
nesting (which is considered fine in Scala although it is frowned upon
by many Java programmers) less type-costly.
Matching braces are always in the same column and nested ones are
indented by K columns along with the nested content.
Looking at any such large nested piece of code from five yards on a
high-res screen I can spot a brace mismatch in a split-second.
But that is a whole different religious war I getting myself into...
At the risk of raining on your religion ...
Throughout my nearly half-century of computing experience, devices
and media on which one reads source code have been wider than they were
tall. Line printers showed ten or eleven dozen columns horizontally,
about five dozen lines vertically. CRT's with hardware-generated fonts
were typically eighty columns wide, twenty-four or -five lines high.
The screen on which I'm typing this message is 1920 pixels wide, 1080
tall -- and with window headers, toolbars, and other decorations using
up more vertical than horizontal space, the usable width is nearly twice
the usable height.
(The only common exception I can recall to "landscape" orientation
was the various Teletype models, whose width was about eighty columns
but whose height was as long as whatever roll of paper you inserted.)
A consequence: Vertical space is scarcer than horizontal space, so
measures to conserve the former are entirely practical. Your example
transformation uses 33% more vertical space than the original; to put
it another way, the original style allows me to read 25% more source
code without scrolling (and perhaps losing my place). Yes, your braces
line up in the same column -- but if one of them floats in the air
above your screen while the other is somewhere underneath your desk
surface, the visual benefits of the arrangement are far from obvious ...
"Go, and sin no more."
--
esosman@comcast-dot-net.invalid