Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #29201 > unrolled thread

Java blunders

Back to article view | Back to comp.lang.java.programmer

Contents

  Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-22 11:41 -0700
    Re: Java blunders Daniele Futtorovic <da.futt.news@laposte.net> - 2014-07-22 21:12 +0200
      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-22 19:46 -0400
        Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 04:14 -0700
    Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-22 23:47 +0200
      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 04:23 -0700
        Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-23 12:32 +0000
          Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-23 08:55 -0400
            Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 06:21 -0700
          Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-23 19:53 -0400
            Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 18:49 -0700
        Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-23 19:52 -0400
    Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-22 19:44 -0400
      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 04:27 -0700
        Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-23 19:55 -0400
          Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 18:53 -0700
            Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-24 11:24 +0200
              Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-25 06:34 -0700
            Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:31 -0400
              Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-25 13:22 -0700
                Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-25 17:17 -0400
                  Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-25 23:12 +0000
                  Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 09:06 -0700
                    Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-26 20:11 +0000
                      Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-26 17:27 -0400
                        Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-27 10:49 -0700
                      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-27 10:10 -0700
                        Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-28 13:53 -0700
                          Re: Java blunders Stuart <DerTopper@web.de> - 2014-07-30 08:05 +0200
                            Re: Java blunders Sebastian <news@seyweiler.dyndns.org> - 2014-07-30 11:12 +0200
                      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-27 10:13 -0700
                        Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-27 18:28 +0000
                          Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-27 14:46 -0400
                            Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-27 21:18 +0000
                              Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-27 18:10 -0400
                                Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-28 01:25 +0000
                                  Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-28 08:02 -0400
                                Re: Java blunders Mike Amling <mamling@chaff.us> - 2014-07-31 13:26 -0500
                                  Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-31 14:48 -0400
                          Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-28 13:22 +0100
                            Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-28 12:52 +0000
                            Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-28 23:38 +0200
                              Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-28 23:17 +0000
                                Re: Java blunders Silvio <silvio@internet.com> - 2014-07-29 13:34 +0200
                                  Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-29 12:45 +0000
                                    Re: Java blunders Silvio <silvio@internet.com> - 2014-07-29 17:10 +0200
                                      Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-29 16:29 +0000
                                        Re: Java blunders lipska the kat <lipskathekat@example.com> - 2014-07-29 20:15 +0100
                                          Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-29 22:02 +0000
                                        Re: Java blunders Silvio <silvio@internet.com> - 2014-07-29 22:43 +0200
                                          Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-29 22:10 +0000
                        Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-27 19:18 -0500
                        Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-28 13:54 -0700
                      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-31 23:07 -0400
                        Re: Java blunders James Hostick <james.hostick@gmail.com> - 2014-08-01 22:10 -0700
              Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 08:31 -0700
                Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-26 21:04 +0000
                  Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-27 10:51 -0700
                  Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-28 08:50 -0700
                    Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-28 23:42 +0200
                Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-31 23:04 -0400
            Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-28 22:23 +0200
              Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-28 16:39 -0400
                Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-29 00:11 +0200
                Re: Java blunders Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2014-07-30 12:07 +0300
                  Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-30 08:05 -0400
      Re: Java blunders Wanja Gayk <brixomatic@yahoo.com> - 2014-07-25 01:34 +0200
        Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:43 -0400
    Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-22 21:02 -0500
      Re: Java blunders Leif Roar Moldskred <leifm@huldreskog.lan> - 2014-07-23 02:01 -0500
        Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 18:58 -0700
        Re: Java blunders thinbluernime <thinbluernime3@gmail.com> - 2014-07-25 03:55 +0000
          Re: Java blunders Leif Roar Moldskred <leifm@huldreskog.lan> - 2014-07-25 00:32 -0500
            Re: Java blunders thinbluernime <thinbluernime3@gmail.com> - 2014-07-26 07:28 +0000
              Re: Java blunders "Gavino" <invalid@invalid.invalid> - 2014-07-26 19:43 +0200
          Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-25 06:36 -0700
            Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-25 15:47 +0100
              Re: Java blunders David Postill <david.postill@gmail.com> - 2014-07-25 18:29 +0200
              Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 09:27 -0700
          Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-25 06:37 -0700
      Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-23 13:17 +0200
        Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 06:27 -0700
      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 04:44 -0700
        Re: Java blunders Silvio <silvio@internet.com> - 2014-07-23 16:23 +0200
          Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-23 12:02 -0400
            Re: Java blunders Silvio <silvio@internet.com> - 2014-07-24 11:37 +0200
              Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-28 22:37 +0200
          Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 09:33 -0700
            Re: Java blunders thinbluernime <thinbluernime3@gmail.com> - 2014-07-25 03:57 +0000
          Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-23 21:38 -0400
            Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 18:59 -0700
              Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-24 07:33 +0000
            Re: Java blunders Silvio <silvio@internet.com> - 2014-07-24 11:47 +0200
              Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:34 -0400
                Re: Java blunders Silvio <silvio@internet.com> - 2014-07-25 08:48 +0200
                  Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-25 08:07 -0400
                    Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-25 13:54 +0100
                  Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-31 22:53 -0400
              Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-25 07:04 -0700
          Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-28 22:01 +0200
        Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-28 21:56 +0200
      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 06:28 -0700
        Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-23 08:33 -0500
      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-23 21:34 -0400
        Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 19:06 -0700
        Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-23 22:11 -0500
          Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-24 07:36 +0000
            Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:39 -0400
              Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-25 13:40 +0100
          Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:38 -0400
            Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-25 13:30 -0700
    Re: Java blunders taqmcg@gmail.com - 2014-07-23 11:26 -0700
      Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-23 15:14 -0400
        Re: Java blunders thinbluernime <thinbluernime3@gmail.com> - 2014-07-25 04:07 +0000
          Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-25 08:35 -0400
            Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 09:41 -0700
          Re: Java blunders Wanja Gayk <brixomatic@yahoo.com> - 2014-08-03 16:41 +0200
            Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-03 11:31 -0400
      Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-23 22:41 -0500
        Re: Java blunders taqmcg@gmail.com - 2014-07-24 10:09 -0700
          Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-25 13:22 +0100
          Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-25 20:34 -0500
            Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-28 13:33 +0100
              Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-28 08:35 -0500
          Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 09:44 -0700
            Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-26 23:36 +0000
    Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-23 20:48 -0700
      Re: Java blunders Silvio <silvio@internet.com> - 2014-07-24 11:56 +0200
        Re: Java blunders Silvio <silvio@internet.com> - 2014-07-24 16:07 +0200
          Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-25 13:38 -0700
            Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 10:02 -0700
      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:29 -0400
        Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-25 13:45 -0700
      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 10:53 -0700
    Re: Java blunders Wanja Gayk <brixomatic@yahoo.com> - 2014-07-25 01:28 +0200
    Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-25 14:16 +0100
    Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-25 17:39 +0200
    Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 16:21 -0700
    Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-28 23:59 +0200
      Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-29 00:41 +0200
        Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-29 01:54 +0200
      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-31 22:38 -0400
      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-31 22:39 -0400
    Re: Java blunders w.tom.adams@gmail.com - 2014-07-30 07:57 -0700
      Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-30 10:22 -0500

Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8  Next page →

#29223

On Tue, 22 Jul 2014 21:02:07 -0500, Joshua Cranmer ������ wrote:

> A. I think languages work best if you need to specify a type name 
> exactly once, e.g., Foo x = new Foo(); is one too many times to say 
> 'Foo'

That seems reasonable until you remember that not all types are a singular
type. How would you change the semantics to shorten "Foo x = new Foo();" by
taking one of the Foo's out while still having the ability to do "Map m =
new HashMap();" ? The two Foo's are not blind, pointless repetition, they
say different things.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#29231

On Wed, 23 Jul 2014 13:17:01 +0200, Joerg Meier <joergmmeier@arcor.de>
wrote, quoted or indirectly quoted someone who said :

>The two Foo's are not blind, pointless repetition, they
>say different things.
 
you could still allow a shortcut

Foo x = new Foo();

Foo() x;

but now the use of interfaces is de rigeur, there is less need for
such a shortcut.

When proofreading I don't like routinely having to study two giant
long names to see if they differ in only one character. That is not a
skill humans excel at.  If they look similar, most programmers will
just presume they are identical.  That is inviting error.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Science is what we understand well enough to explain to a computer.
Art is everything else we do. 
~ Donald Ervin Knuth (born: 1938-01-10 age: 76)

[toc] | [prev] | [next] | [standalone]

#29227

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

-- 
Roedy Green Canadian Mind Products http://mindprod.com
Science is what we understand well enough to explain to a computer.
Art is everything else we do. 
~ Donald Ervin Knuth (born: 1938-01-10 age: 76)

[toc] | [prev] | [next] | [standalone]

#29235

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

[toc] | [prev] | [next] | [standalone]

#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 ?
>> <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

[toc] | [prev] | [next] | [standalone]

#29265

On 07/23/2014 06:02 PM, Eric Sosman wrote:
>
>      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."
>

I disagree. Physical vertical space is scarcer than physical horizontal 
space but human beings are not good at reading wide block of text while 
they have no problem reading lots of lines of text.

For that reason it is better to spread content vertically. Look at how 
websites center in a fixed width small portion of the screen and then 
flow vertically or how newspapers use narrow columns of text on large 
(wide) enough paper.

For that same reason an extra line that contains a single structure 
marking character puts a very small burden on the human eye while 
helping a lot in readability.

[toc] | [prev] | [next] | [standalone]

#29405

On 07/24/2014 11:37 AM, Silvio wrote:
>
> I disagree. Physical vertical space is scarcer than physical horizontal
> space but human beings are not good at reading wide block of text while
> they have no problem reading lots of lines of text.

Agreed on that.

> For that reason it is better to spread content vertically. Look at how
> websites center in a fixed width small portion of the screen and then
> flow vertically or how newspapers use narrow columns of text on large
> (wide) enough paper.
>
> For that same reason an extra line that contains a single structure
> marking character puts a very small burden on the human eye while
> helping a lot in readability.

I disagree.
A single extra line for every structure spreads structures vertically.
Structures become visually larger, and less structures fit on the screen.
As the result, code readability declines, since the ability to find the 
right structure requires scrolling.
Big picture matters.

But it's matter of taste really.
We have nice IDEs, click braces this, click brackets that, click 
arrange, and done.

Regards...

[toc] | [prev] | [next] | [standalone]

#29238

On Wed, 23 Jul 2014 16:23:16 +0200, Silvio <silvio@internet.com>
wrote, quoted or indirectly quoted someone who said :

>if (IHadABell)
>{
>    IdRingItInTheMorning();
>}
 I do that.

I think most common problem in copy pasting bits of code about. IF I
don't grab a balanced chunk, I am in deep trouble, especially if the
fragment is large.

More and more I use IntelliJ to move things around.  It never screws
up that way, and it does a fair bit of touch up automatically.

I thought perhaps we should think of code as blocks, not text, like
atomic physical objects that have to be moved about as lumps.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Science is what we understand well enough to explain to a computer.
Art is everything else we do. 
~ Donald Ervin Knuth (born: 1938-01-10 age: 76)

[toc] | [prev] | [next] | [standalone]

#29295

On Wed, 23 Jul 2014 09:33:36 -0700, Roedy Green wrote:

> I think most common problem in copy pasting bits of code about. IF I
> don't grab a balanced chunk, I am in deep trouble, especially if the
> fragment is large.
> 
> More and more I use IntelliJ to move things around.  It never screws up
> that way, and it does a fair bit of touch up automatically.
> 
> I thought perhaps we should think of code as blocks, not text, like
> atomic physical objects that have to be moved about as lumps.

Congratulations. You've just invented Lisp's concept of s-expressions, 
and paredit.
:)

[toc] | [prev] | [next] | [standalone]

#29249

On 7/23/2014 10:23 AM, Silvio wrote:
> On 07/23/2014 01:44 PM, Roedy Green wrote:
>> 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 can not see why it should be that much easier to match { with } than
to match if with }.

Arne

[toc] | [prev] | [next] | [standalone]

#29253

On Wed, 23 Jul 2014 21:38:46 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>I can not see why it should be that much easier to match { with } than
>to match if with }.

When they are aligned, low level visual processing helps with the
work.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Science is what we understand well enough to explain to a computer.
Art is everything else we do. 
~ Donald Ervin Knuth (born: 1938-01-10 age: 76)

[toc] | [prev] | [next] | [standalone]

#29260

On Wed, 23 Jul 2014 18:59:27 -0700, Roedy Green wrote:

> On Wed, 23 Jul 2014 21:38:46 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
> 
>>I can not see why it should be that much easier to match { with } than
>>to match if with }.
> 
> When they are aligned, low level visual processing helps with the work.

+1


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29266

On 07/24/2014 03:38 AM, Arne Vajhøj wrote:
> On 7/23/2014 10:23 AM, Silvio wrote:
>> On 07/23/2014 01:44 PM, Roedy Green wrote:
>>> 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 can not see why it should be that much easier to match { with } than
> to match if with }.
>
> Arne
>

Braces are visually symmetric which makes matching by glance (not by 
actual reading) much easier. But it is not so much matching if with }, 
you have to assure yourself that there is a { at the end of the line 
containing the if. Since the if-condition will vary in length the { will 
always be in different positions which makes it non-glance-parsable to 
the human eye.

if (IHadASong)
    IdSingItInTheMorning();
}

is a syntax error although if and } match. The presence/absence of the { 
at the end of the condition is the key thing here and that is not on the 
critical reading path that the left margin is.

[toc] | [prev] | [next] | [standalone]

#29282

On 7/24/2014 5:47 AM, Silvio wrote:
> On 07/24/2014 03:38 AM, Arne Vajhøj wrote:
>> On 7/23/2014 10:23 AM, Silvio wrote:
>>> On 07/23/2014 01:44 PM, Roedy Green wrote:
>>>> 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 can not see why it should be that much easier to match { with } than
>> to match if with }.
>
> Braces are visually symmetric which makes matching by glance (not by
> actual reading) much easier.

That I can not see why.

>                             But it is not so much matching if with },
> you have to assure yourself that there is a { at the end of the line
> containing the if. Since the if-condition will vary in length the { will
> always be in different positions which makes it non-glance-parsable to
> the human eye.
>
> if (IHadASong)
>     IdSingItInTheMorning();
> }
>
> is a syntax error although if and } match. The presence/absence of the {
> at the end of the condition is the key thing here and that is not on the
> critical reading path that the left margin is.

But we have a nice compiler that will tell us if the brace is missing.

Missing brace is not a real problem. Reading code is a real problem.

Arne

[toc] | [prev] | [next] | [standalone]

#29302

On 07/25/2014 01:34 AM, Arne Vajhøj wrote:
> On 7/24/2014 5:47 AM, Silvio wrote:
>> On 07/24/2014 03:38 AM, Arne Vajhøj wrote:
>>> On 7/23/2014 10:23 AM, Silvio wrote:
>>>> On 07/23/2014 01:44 PM, Roedy Green wrote:
>>>>> 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 can not see why it should be that much easier to match { with } than
>>> to match if with }.
>>
>> Braces are visually symmetric which makes matching by glance (not by
>> actual reading) much easier.
>
> That I can not see why.

Most will agree it is easier to visually parse

(((a - b) * (c + d) + e) * f)

than

begin begin begin a - b end * begin c + d end + e end * f end

In Algol68 they where synonyms although most used () for expressions and 
begin/end for blocks. But I knew quite some people who preferred () for 
all cases because of the improved readability.

>
>>                             But it is not so much matching if with },
>> you have to assure yourself that there is a { at the end of the line
>> containing the if. Since the if-condition will vary in length the { will
>> always be in different positions which makes it non-glance-parsable to
>> the human eye.
>>
>> if (IHadASong)
>>     IdSingItInTheMorning();
>> }
>>
>> is a syntax error although if and } match. The presence/absence of the {
>> at the end of the condition is the key thing here and that is not on the
>> critical reading path that the left margin is.
>
> But we have a nice compiler that will tell us if the brace is missing.
>
> Missing brace is not a real problem. Reading code is a real problem.
>
> Arne
>
>

We where talking about being able to visually detect block nesting 
errors so that is hardly an argument. I for one try to assure myself 
that code is correct before trying anything else with it. IDE error 
highlighting is less than helpful in these cases.

The compiler will complain for any syntax error and will also do that in 
this case. But unless you have made your own better compiler the error 
you receive when this code fragment is an already nested part of a 
larger block will be less than informative about where the error is 
located and may even be about something completely different than having 
a superfluous }

[toc] | [prev] | [next] | [standalone]

#29303

On 7/25/2014 2:48 AM, Silvio wrote:
>[...]
> Most will agree it is easier to visually parse
>
> (((a - b) * (c + d) + e) * f)
> [...]

     ... but haven't you been arguing for

	(
	   (
	      (
	         a - b
	      )
	      *
	      (
	         c + d
	      )
	      +
	      e
	   )
	   *
	   f
	)

... so it's visually easy to match openings and closings?

    ;-)

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#29307

Eric Sosman wrote:
> On 7/25/2014 2:48 AM, Silvio wrote:
> > [...]
> > Most will agree it is easier to visually parse
> >
> > (((a - b) * (c + d) + e) * f)
> > [...]
>
>     ... but haven't you been arguing for
>
> (
>    (
>       (
>          a - b
>       )
>       *
>       (
>          c + d
>       )
>       +
>       e
>    )
>    *
>    f
> )
>
> ... so it's visually easy to match openings and closings?
>
>    ;-)

Seen the smiley, but:

(A) you disagree with me about perfect brace layout -- and so should be burned 
forthwith.

(B) there really is a point about clear layout of complex expressions here.

In code with complex expressions, there is a lot to be gained by (obviously) 
breaking them over several lines, and /also/ putting the main connective at the 
/start/ of each line rather than "hiding" it at the end.  The same idea as 
putting the { at the start of it's line, rather than "hiding" it at the end (as 
blasphemous dogs do).

    if (theConditionIsComplex
    && itsHardToReadOnOneLine
    && itHasARegularPattern
    && (theWriterIsntABlasphemousDog || localCodingConventionsAreOptimal))
    {
        layItOutLikeThis();
    }

And yes, if[*] the conditions inside the && (... || ...) brackets were complex 
enough to need internal line breaks, then I'd lay it out with vertically 
matching ()s.

    -- chris

[*] Hardly ever happens except when writing complex SQL. 

[toc] | [prev] | [next] | [standalone]

#29476

On 7/25/2014 2:48 AM, Silvio wrote:
> On 07/25/2014 01:34 AM, Arne Vajhøj wrote:
>> On 7/24/2014 5:47 AM, Silvio wrote:
>>> On 07/24/2014 03:38 AM, Arne Vajhøj wrote:
>>>> On 7/23/2014 10:23 AM, Silvio wrote:
>>>>> On 07/23/2014 01:44 PM, Roedy Green wrote:
>>>>>> 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 can not see why it should be that much easier to match { with } than
>>>> to match if with }.
>>>
>>> Braces are visually symmetric which makes matching by glance (not by
>>> actual reading) much easier.
>>
>> That I can not see why.
>
> Most will agree it is easier to visually parse
>
> (((a - b) * (c + d) + e) * f)
>
> than
>
> begin begin begin a - b end * begin c + d end + e end * f end

True.

But I am not sure that what is optimal for expressions is optimal for
block statements.

I like the entire expression in one line - I do not like the entire
block of statements either.

>>>                             But it is not so much matching if with },
>>> you have to assure yourself that there is a { at the end of the line
>>> containing the if. Since the if-condition will vary in length the { will
>>> always be in different positions which makes it non-glance-parsable to
>>> the human eye.
>>>
>>> if (IHadASong)
>>>     IdSingItInTheMorning();
>>> }
>>>
>>> is a syntax error although if and } match. The presence/absence of the {
>>> at the end of the condition is the key thing here and that is not on the
>>> critical reading path that the left margin is.
>>
>> But we have a nice compiler that will tell us if the brace is missing.
>>
>> Missing brace is not a real problem. Reading code is a real problem.
>
> We where talking about being able to visually detect block nesting
> errors so that is hardly an argument.

You mean missing braces.

That is a valid point.

But then see it as an argument that it is not a big problem.

> The compiler will complain for any syntax error and will also do that in
> this case. But unless you have made your own better compiler the error
> you receive when this code fragment is an already nested part of a
> larger block will be less than informative about where the error is
> located and may even be about something completely different than having
> a superfluous }

I can not recognize this at all.

I have never spend much time looking for brace mismatch - and I don't
think I have ever met anyone that has.

I have and know many that have spent hours/days/weeks reading code
and trying to understand the block structure.

Arne

[toc] | [prev] | [next] | [standalone]

#29312

On Thu, 24 Jul 2014 11:47:08 +0200, Silvio <silvio@internet.com>
wrote, quoted or indirectly quoted someone who said :

>Braces are visually symmetric 

But if you have more than one pair, it not easy to pair them up unless
the matching pairs are visually distinctive. My favourite scheme is
simply to use bigger braces on the outside. Mathematicians have been
doing this for centuries.

Because of the punch card  with FORTRAN we abandoned our inheritance
of mathematical notation. Now we have a graphical interface, I think
IDEs should start typesetting expressions much as they would a appear
in a math text, e.g. showing division numerator over denominator,
using super and subscripts.


-- 
Roedy Green Canadian Mind Products http://mindprod.com
Science is what we understand well enough to explain to a computer.
Art is everything else we do. 
~ Donald Ervin Knuth (born: 1938-01-10 age: 76)

[toc] | [prev] | [next] | [standalone]

#29403

On 07/23/2014 04:23 PM, Silvio wrote:
>
> 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.

Simply, It's more compact.
Editor takes care of the rest.
And our sallaries are not based on lines of code written ;(

Regards...

[toc] | [prev] | [next] | [standalone]

Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web