Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Java blunders Date: Wed, 23 Jul 2014 12:02:23 -0400 Organization: A noiseless patient Spider Lines: 104 Message-ID: References: <257vs95667e2rm9ff40h8n5bchmc2mv3iu@4ax.com> <53cfc554$0$2860$e4fe514c@news.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 23 Jul 2014 16:02:26 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="bd4e1cba8d8592bec5d5ed9e4537fbfd"; logging-data="7648"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18m3FHps0pbmMklJyX86pPS" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <53cfc554$0$2860$e4fe514c@news.xs4all.nl> Cancel-Lock: sha1:t2VPYWI7OskjsPYiaSYz1d208Gw= Xref: csiph.com comp.lang.java.programmer:29237 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 ? >> 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