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

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

Holy boop: goto for Java

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

Contents

  Holy boop: goto for Java markspace <-@.> - 2012-06-03 19:36 -0700
    Re: Holy boop: goto for Java Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-03 20:03 -0700
      Re: Holy boop: goto for Java markspace <-@.> - 2012-06-03 20:30 -0700
        Re: Holy boop: goto for Java Lew <noone@lewscanon.com> - 2012-06-03 21:17 -0700
          Re: Holy boop: goto for Java Robert Klemme <shortcutter@googlemail.com> - 2012-06-04 07:56 +0200
          Re: Holy boop: goto for Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-06-04 04:28 -0300
            Re: Holy boop: goto for Java Robert Klemme <shortcutter@googlemail.com> - 2012-06-04 00:37 -0700
              Re: Holy boop: goto for Java Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-04 07:43 -0700
                Re: Holy boop: goto for Java "Mike Schilling" <mscottschilling@hotmail.com> - 2012-06-04 07:47 -0700
                  Re: Holy boop: goto for Java "Mike Schilling" <mscottschilling@hotmail.com> - 2012-06-04 08:17 -0700
              Re: Holy boop: goto for Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-06-04 17:07 -0300
                Re: Holy boop: goto for Java Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-04 13:17 -0700
                  Re: Holy boop: goto for Java Gene Wirchenko <genew@ocis.net> - 2012-06-04 14:46 -0700
                    Re: Holy boop: goto for Java Robert Klemme <shortcutter@googlemail.com> - 2012-06-05 07:31 +0200
                      Re: Holy boop: goto for Java Gene Wirchenko <genew@ocis.net> - 2012-06-05 09:15 -0700
                        Re: Holy boop: goto for Java Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-05 10:51 -0700
                          Re: Holy boop: goto for Java Gene Wirchenko <genew@ocis.net> - 2012-06-05 10:54 -0700
                          Re: Holy boop: goto for Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-06-06 05:58 -0300
                            Re: Holy boop: goto for Java Lew <lewbloch@gmail.com> - 2012-06-06 12:11 -0700
                        Re: Holy boop: goto for Java Robert Klemme <shortcutter@googlemail.com> - 2012-06-05 23:24 +0200
                          Re: Holy boop: goto for Java Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-05 17:30 -0400
                            Re: Holy boop: goto for Java Gene Wirchenko <genew@ocis.net> - 2012-06-05 20:06 -0700
              Re: Holy boop: goto for Java Patricia Shanahan <pats@acm.org> - 2012-07-22 06:37 -0700
                Re: Holy boop: goto for Java Chris Riesbeck <Chris.Riesbeck@gmail.com> - 2012-07-23 13:27 -0500
                  Re: Holy boop: goto for Java Gene Wirchenko <genew@ocis.net> - 2012-07-23 13:23 -0700
            Re: Holy boop: goto for Java Lew <lewbloch@gmail.com> - 2012-06-04 09:33 -0700
          Re: Holy boop: goto for Java Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-06-04 07:26 -0400
          Re: Holy boop: goto for Java "Mike Schilling" <mscottschilling@hotmail.com> - 2012-06-04 07:44 -0700
            Re: Holy boop: goto for Java Robert Klemme <shortcutter@googlemail.com> - 2012-06-04 18:13 +0200
              Re: Holy boop: goto for Java Gene Wirchenko <genew@ocis.net> - 2012-06-04 10:23 -0700
                Re: Holy boop: goto for Java Lew <lewbloch@gmail.com> - 2012-06-04 10:45 -0700
                  Re: Holy boop: goto for Java Robert Klemme <shortcutter@googlemail.com> - 2012-06-04 20:31 +0200
                  Re: Holy boop: goto for Java Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-04 11:52 -0700
                    Re: Holy boop: goto for Java Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-06-04 14:15 -0500
                    Re: Holy boop: goto for Java Lew <lewbloch@gmail.com> - 2012-06-04 14:52 -0700
            Re: Holy boop: goto for Java Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-04 10:50 -0700
            Re: Holy boop: goto for Java Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-04 10:56 -0700
            Re: Holy boop: goto for Java Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-06-04 13:05 -0500
      Re: Holy boop: goto for Java Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-06-04 07:28 -0400
    Re: Holy boop: goto for Java Roedy Green <see_website@mindprod.com.invalid> - 2012-06-03 22:10 -0700

Page 1 of 2  [1] 2  Next page →

#15027 — Holy boop: goto for Java

Just looking for an extended answer to an earlier question (strings in a 
case-switch statement), I found this on Joe Darcy's blog:

"Summary

"Provide the benefits of the time-testing goto control structure to Java 
programs. The Java language has a history of adding new control 
structures over time, the assert statement in 1.4, the enhanced for-loop 
in 1.5,and try-with-resources in 7. Having support for goto is 
long-overdue and simple to implement since the JVM already has goto 
instructions."

<https://blogs.oracle.com/darcy/entry/upcoming_jep>

Holy booping bat boop Batman!

[toc] | [next] | [standalone]

#15028

On 6/3/12 7:36 PM, markspace wrote:
> Just looking for an extended answer to an earlier question (strings in a
> case-switch statement), I found this on Joe Darcy's blog:
>
> "Summary
>
> "Provide the benefits of the time-testing goto control structure to Java
> programs. The Java language has a history of adding new control
> structures over time, the assert statement in 1.4, the enhanced for-loop
> in 1.5,and try-with-resources in 7. Having support for goto is
> long-overdue and simple to implement since the JVM already has goto
> instructions."
>
> <https://blogs.oracle.com/darcy/entry/upcoming_jep>
>
> Holy booping bat boop Batman!
>
Check the date of that article before getting to excited/disappointed ;-)

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

#15029

On 6/3/2012 8:03 PM, Daniel Pitts wrote:
> Check the date of that article before getting to excited/disappointed ;-)


Ah.  Somebody got me good, I think.

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

#15030

markspace wrote:
> Daniel Pitts wrote:
>> Check the date of that article before getting to excited/disappointed ;-)
>
> Ah. Somebody got me good, I think.

In a highly limited, controlled and presumably blessed-for-object-oriented 
way, Java does have a version of "goto", in its 'break' and 'continue' 
statements. You can't just jump anywhere, but you can jump to labels, with 
restrictions.

I have never seen a use of Java's labeled 'break' or 'continue' outside of 
tutorials and examples, though.

The full, unbridled "goto" doesn't exist in Java except for the keyword 
'goto', whose head is mounted on a pike at the language's gates as a warning.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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

#15032

On 04.06.2012 06:17, Lew wrote:
> The full, unbridled "goto" doesn't exist in Java except for the keyword
> 'goto', whose head is mounted on a pike at the language's gates as a
> warning.

I'll print that and put it on our office door.  Thanks for that, Lew!

Chuckle...

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

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

#15033

On 12-06-04 01:17 AM, Lew wrote:
> markspace wrote:
>> Daniel Pitts wrote:
>>> Check the date of that article before getting to excited/disappointed
>>> ;-)
>>
>> Ah. Somebody got me good, I think.
>
> In a highly limited, controlled and presumably
> blessed-for-object-oriented way, Java does have a version of "goto", in
> its 'break' and 'continue' statements. You can't just jump anywhere, but
> you can jump to labels, with restrictions.
>
> I have never seen a use of Java's labeled 'break' or 'continue' outside
> of tutorials and examples, though.
>
> The full, unbridled "goto" doesn't exist in Java except for the keyword
> 'goto', whose head is mounted on a pike at the language's gates as a
> warning.
>
I use labeled break/continue occasionally. I see a lot of advice on 
programming forums like StackOverflow that says never use them. Typical 
dogmatic advice is that you should extract inner-loop code into methods 
and use boolean return codes to make a top-level break/continue decision.

What amazes me is that these individuals support this religious stance 
by arguing that it improves readability, when producing little auxiliary 
methods usually does anything but.

The combination of conditions that would indicate a labeled 
break/continue is clear:

1. A loop;
2. A condition in that loop that could lead to a break or continue for it;
3. That condition is itself a loop. Furthermore, the logic in the loop 
is probably coupled to the logic in the rest of the main loop.

To the degree that the logic in that inner loop makes (no) sense as a 
standalone method - size, understandability on its own etc - is the 
decision process I follow as to whether a labeled break/continue is 
advisable.

In any case, Lew, I don't see that this has much to do with "blessed for 
OO". We're talking imperative coding here, which is what Java 
programmers spend the majority of their time doing.

AHS
-- 
Never interrupt your enemy when he is making a mistake.
--Napoleon

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

#15034

On Monday, June 4, 2012 9:28:13 AM UTC+2, Arved Sandstrom wrote:
> What amazes me is that these individuals support this religious stance 
> by arguing that it improves readability, when producing little auxiliary 
> methods usually does anything but.

I am not religious about break / continue (although I use it extremely seldom, I am more likely to use "return" inside a loop).  But I disagree about your general statement about little auxiliary methods usually not improving readability.  It all depends on the specific case, of course, but giving a short part of an algorithm a name (with the option to have a place to put JavaDoc) often helps readability in my experience.

Kind regards

robert

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

#15038

On 6/4/12 12:37 AM, Robert Klemme wrote:
> On Monday, June 4, 2012 9:28:13 AM UTC+2, Arved Sandstrom wrote:
>> What amazes me is that these individuals support this religious stance
>> by arguing that it improves readability, when producing little auxiliary
>> methods usually does anything but.
>
> I am not religious about break / continue (although I use it extremely seldom, I am more likely to use "return" inside a loop).  But I disagree about your general statement about little auxiliary methods usually not improving readability.  It all depends on the specific case, of course, but giving a short part of an algorithm a name (with the option to have a place to put JavaDoc) often helps readability in my experience.
+1

I rarely have methods that are more than 10 lines long anymore, thanks 
to "Extract Method" and other refactorings. This sort of goes along with 
"self-documenting" code.  Now granted, someone could start naming these 
auxiliary methods in such a way to be contrary to the goal of 
readability, but that's just bad programming.  I find a well named 
method often removes a hastily written comment. For example:

---
while (isYSquibled()) {...}
---

versus

---
//Loop while x squibles y.
while (x == null || y.canBeSquibledBy(x)) {...}
---

Another thing I've noticed is that programmers are less likely to change 
the method to do something-else without renaming the method, but are 
more likely to forget or ignore comments explaining what a single line 
does.

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

#15040

Daniel Pitts wrote:
>
> Another thing I've noticed is that programmers are less likely to
> change the method to do something-else without renaming the method,
> but are more likely to forget or ignore comments explaining what a
> single line does.

y = 12; // set Y to 10 

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

#15044

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message 
news:012-20120604170339@ram.dialup.fu-berlin.de...
> "Mike Schilling" <mscottschilling@hotmail.com> writes:
>>y = 12; // set Y to 10
>
>  y = 012; // set y to 10
>

Nice.  It's like the proof that Halloween equals Christmas

    Dec 25 == Oct 31 

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

#15061

On 12-06-04 04:37 AM, Robert Klemme wrote:
> On Monday, June 4, 2012 9:28:13 AM UTC+2, Arved Sandstrom wrote:
>> What amazes me is that these individuals support this religious stance
>> by arguing that it improves readability, when producing little auxiliary
>> methods usually does anything but.
>
> I am not religious about break / continue (although I use it extremely seldom, I am more likely to use "return" inside a loop).  But I disagree about your general statement about little auxiliary methods usually not improving readability.  It all depends on the specific case, of course, but giving a short part of an algorithm a name (with the option to have a place to put JavaDoc) often helps readability in my experience.
>
> Kind regards
>
> robert

When I mean "little", I mean little - like 2 or 3 lines little. Based on 
the "no exceptions NEVER use labeled break/continue" language that I've 
seen in threads on this subject, and the invariable suggestion of using 
extracted helper methods instead, this *inevitably* means that many of 
these helper methods will be that small. After all, the body of such a 
method would be whatever the body of the inner loop is, and in my 
experience that's often small.

I am not super-dogmatic about many things, but one thing I will not 
yield ground on is the readability hit of little (1-3 lines of Java) 
methods. *Sometimes*, with a well-chosen name, and general 
applicability, these are perfectly OK. But these idiots in these threads 
I allude to are talking about extracting all code in an inner loop, if 
it would require a conditional break or continue, robotically making a 
method out of it - even if that outer loop is the only caller - without 
any intelligent thought whatsoever.

Can you imagine what kind of names such methods might have? How about 
"innerLoopStuff()"?

AHS

-- 
Never interrupt your enemy when he is making a mistake.
--Napoleon

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

#15062

On 6/4/12 1:07 PM, Arved Sandstrom wrote:
> On 12-06-04 04:37 AM, Robert Klemme wrote:
>> On Monday, June 4, 2012 9:28:13 AM UTC+2, Arved Sandstrom wrote:
>>> What amazes me is that these individuals support this religious stance
>>> by arguing that it improves readability, when producing little auxiliary
>>> methods usually does anything but.
>>
>> I am not religious about break / continue (although I use it extremely
>> seldom, I am more likely to use "return" inside a loop). But I
>> disagree about your general statement about little auxiliary methods
>> usually not improving readability. It all depends on the specific
>> case, of course, but giving a short part of an algorithm a name (with
>> the option to have a place to put JavaDoc) often helps readability in
>> my experience.
>>
>> Kind regards
>>
>> robert
>
> When I mean "little", I mean little - like 2 or 3 lines little. Based on
> the "no exceptions NEVER use labeled break/continue" language that I've
> seen in threads on this subject, and the invariable suggestion of using
> extracted helper methods instead, this *inevitably* means that many of
> these helper methods will be that small. After all, the body of such a
> method would be whatever the body of the inner loop is, and in my
> experience that's often small.
>
> I am not super-dogmatic about many things, but one thing I will not
> yield ground on is the readability hit of little (1-3 lines of Java)
> methods. *Sometimes*, with a well-chosen name, and general
> applicability, these are perfectly OK. But these idiots in these threads
> I allude to are talking about extracting all code in an inner loop, if
> it would require a conditional break or continue, robotically making a
> method out of it

No need to call me an idiot. Actually, I don't advocate "extracting all 
code in an inner loop, if it would require a conditional break or 
continue".  I advocate distinct intuitive steps into simple methods, 
always, unless you have a specific reason not to.  A good reason, not 
just any reason.

Many experts in the field of software design agree. I learned this 
practice directly from Martin Fowler as a matter of fact, in a training 
session he did on TDD at my company.

> - even if that outer loop is the only caller -
Who calls a method is irrelevant to only value of such a method, unless 
the number of callers is zero of course.
> without any intelligent thought whatsoever.
Intelligent thought is always required, for all software design. The 
problem is when people do things by guessing.
>
> Can you imagine what kind of names such methods might have? How about
> "innerLoopStuff()"?
It depends on the loop. How about instead "processNextStuff()" (where 
stuff is replaced with a meaningful name).

I'm not going to say "It must always be done!" but I will say that when 
done *right*, it will improve the maintainability of the code base 
significantly.

Thanks,
Daniel
Yet Another Idiot Apparently.

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

#15064

On Mon, 04 Jun 2012 13:17:21 -0700, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote:

>On 6/4/12 1:07 PM, Arved Sandstrom wrote:
>> On 12-06-04 04:37 AM, Robert Klemme wrote:
>>> On Monday, June 4, 2012 9:28:13 AM UTC+2, Arved Sandstrom wrote:
>>>> What amazes me is that these individuals support this religious stance
>>>> by arguing that it improves readability, when producing little auxiliary
>>>> methods usually does anything but.

     Personally, I find this sort of stuff to be very unreadable.  If
it is used multiple times, it is not quite so bad.  If it is used but
once, it is a disruption to following the caller.

>>> I am not religious about break / continue (although I use it extremely
>>> seldom, I am more likely to use "return" inside a loop). But I
>>> disagree about your general statement about little auxiliary methods
>>> usually not improving readability. It all depends on the specific
>>> case, of course, but giving a short part of an algorithm a name (with
>>> the option to have a place to put JavaDoc) often helps readability in
>>> my experience.

>> When I mean "little", I mean little - like 2 or 3 lines little. Based on
>> the "no exceptions NEVER use labeled break/continue" language that I've
>> seen in threads on this subject, and the invariable suggestion of using
>> extracted helper methods instead, this *inevitably* means that many of
>> these helper methods will be that small. After all, the body of such a
>> method would be whatever the body of the inner loop is, and in my
>> experience that's often small.

     There is also context to consider.  I have sometimes considered
moving some short, common code to subroutines to find that by the time
I re-established the context in the subroutine, the subroutine's code
would be longer than having the code in the caller.

>> I am not super-dogmatic about many things, but one thing I will not
>> yield ground on is the readability hit of little (1-3 lines of Java)
>> methods. *Sometimes*, with a well-chosen name, and general
>> applicability, these are perfectly OK. But these idiots in these threads
>> I allude to are talking about extracting all code in an inner loop, if
>> it would require a conditional break or continue, robotically making a
>> method out of it

     That is extreme.

>No need to call me an idiot. Actually, I don't advocate "extracting all 
>code in an inner loop, if it would require a conditional break or 
>continue".  I advocate distinct intuitive steps into simple methods, 
>always, unless you have a specific reason not to.  A good reason, not 
>just any reason.

     You are talking past each other.  He is not talking about
intuitive steps, but just automatic "methodising" of code.

>Many experts in the field of software design agree. I learned this 
>practice directly from Martin Fowler as a matter of fact, in a training 
>session he did on TDD at my company.
>
>> - even if that outer loop is the only caller -
>Who calls a method is irrelevant to only value of such a method, unless 
>the number of callers is zero of course.

     If it is only one, in-line might be better.

>> without any intelligent thought whatsoever.
>Intelligent thought is always required, for all software design. The 
>problem is when people do things by guessing.

     Or by manifesto which is much the same.

>> Can you imagine what kind of names such methods might have? How about
>> "innerLoopStuff()"?
>It depends on the loop. How about instead "processNextStuff()" (where 
>stuff is replaced with a meaningful name).

     innerLoopStuff2(), innerLoopStuff3(), ... ?

>I'm not going to say "It must always be done!" but I will say that when 
>done *right*, it will improve the maintainability of the code base 
>significantly.

     But then it probably would be done as the code is written,
because it is a sensible -- what you called "intuitive" above --
design.

     I like my code to tell a story at one level of abstraction.  It
makes it easier to follow the logic.  The high-level code is all in
one sequence.  With this, I can skip the lower-level logic most of the
time.  If I need to adjust the higher-level logic, it is a good sign
when I do not have to concern myself much with the lower-level logic
(because what I came up with for it is still what is needed).

>Thanks,
>Daniel
>Yet Another Idiot Apparently.

     Nope.  You are too thoughtful for that.

Sincerely,

Gene Wirchenko

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

#15069

On 04.06.2012 23:46, Gene Wirchenko wrote:
> On Mon, 04 Jun 2012 13:17:21 -0700, Daniel Pitts
> <newsgroup.nospam@virtualinfinity.net>  wrote:
>
>> On 6/4/12 1:07 PM, Arved Sandstrom wrote:
>>> On 12-06-04 04:37 AM, Robert Klemme wrote:
>>>> On Monday, June 4, 2012 9:28:13 AM UTC+2, Arved Sandstrom wrote:
>>>>> What amazes me is that these individuals support this religious stance
>>>>> by arguing that it improves readability, when producing little auxiliary
>>>>> methods usually does anything but.
>
>       Personally, I find this sort of stuff to be very unreadable.  If
> it is used multiple times, it is not quite so bad.  If it is used but
> once, it is a disruption to following the caller.

Hmm, but with that argument you must put everything in one method - what 
you clearly do not do as your later comments show. :-)

>       There is also context to consider.  I have sometimes considered
> moving some short, common code to subroutines to find that by the time
> I re-established the context in the subroutine, the subroutine's code
> would be longer than having the code in the caller.

Right.  Or if argument lists get too long that is also a good sign that 
something is wrong.

>       I like my code to tell a story at one level of abstraction.

That's an interesting way to put it.  And it hits the nail on the head.

> It makes it easier to follow the logic.  The high-level code is all in
> one sequence.  With this, I can skip the lower-level logic most of the
> time.  If I need to adjust the higher-level logic, it is a good sign
> when I do not have to concern myself much with the lower-level logic
> (because what I came up with for it is still what is needed).

Right!  That discussion nicely shows why it still needs humans to write 
software: the process of cutting algorithms in parts cannot be easily 
automated.  One reason for that is that we do not write for machines 
(which easily cope with the most contrived code as long as it compiles) 
but rather for humans - namely the one who comes after us and has to fix 
a bug or add a feature.

Kind regard

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

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

#15076

On Tue, 05 Jun 2012 07:31:44 +0200, Robert Klemme
<shortcutter@googlemail.com> wrote:

>On 04.06.2012 23:46, Gene Wirchenko wrote:
>> On Mon, 04 Jun 2012 13:17:21 -0700, Daniel Pitts
>> <newsgroup.nospam@virtualinfinity.net>  wrote:
>>
>>> On 6/4/12 1:07 PM, Arved Sandstrom wrote:
>>>> On 12-06-04 04:37 AM, Robert Klemme wrote:
>>>>> On Monday, June 4, 2012 9:28:13 AM UTC+2, Arved Sandstrom wrote:
>>>>>> What amazes me is that these individuals support this religious stance
>>>>>> by arguing that it improves readability, when producing little auxiliary
>>>>>> methods usually does anything but.
>>
>>       Personally, I find this sort of stuff to be very unreadable.  If
>> it is used multiple times, it is not quite so bad.  If it is used but
>> once, it is a disruption to following the caller.
>
>Hmm, but with that argument you must put everything in one method - what 
>you clearly do not do as your later comments show. :-)

     NO!  Pulling some code out to make it a method that is called
ONLY ONCE is what I object to.  (I might do it if there is
clearly-delineated functionality that could be useful again (but just
happens to be needed but once when it written)).  I will not do it for
some manifesto.

>>       There is also context to consider.  I have sometimes considered
>> moving some short, common code to subroutines to find that by the time
>> I re-established the context in the subroutine, the subroutine's code
>> would be longer than having the code in the caller.
>
>Right.  Or if argument lists get too long that is also a good sign that 
>something is wrong.

     Yes.  I should have included length of calling sequence.

>>       I like my code to tell a story at one level of abstraction.
>
>That's an interesting way to put it.  And it hits the nail on the head.

     I hit on it several years ago.  Many of my programs or large
segments have one story with the rest of the methods/subroutines
supporting it.  A consequence of this is that some of my methods can
get rather long (ones that tell a story).

>> It makes it easier to follow the logic.  The high-level code is all in
>> one sequence.  With this, I can skip the lower-level logic most of the
>> time.  If I need to adjust the higher-level logic, it is a good sign
>> when I do not have to concern myself much with the lower-level logic
>> (because what I came up with for it is still what is needed).
>
>Right!  That discussion nicely shows why it still needs humans to write 
>software: the process of cutting algorithms in parts cannot be easily 
>automated.  One reason for that is that we do not write for machines 
>(which easily cope with the most contrived code as long as it compiles) 
>but rather for humans - namely the one who comes after us and has to fix 
>a bug or add a feature.

     Which is often us so being nice to the maintenance programmer is
being nice to oneself.

     Besides the story paradigm, I also think in terms of program
usefulness.  If a program is not very useful, one can write it pretty
much any way one wants as the program is going to get tossed anyway.
If it is useful, then it is going to stick around, and requirements
have a way of changing so the program had better be maintainable.  It
can also be difficult to tell whether a program will be useful so why
not just write them all clearly?

Sincerely,

Gene Wirchenko

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

#15078

On 6/5/12 9:15 AM, Gene Wirchenko wrote:
>       NO!  Pulling some code out to make it a method that is called
> ONLY ONCE is what I object to.  (I might do it if there is
> clearly-delineated functionality that could be useful again (but just
> happens to be needed but once when it written)).  I will not do it for
> some manifesto.

Code re-usability is the great lie that has become the manifesto, not 
pulling out a once-used method.

You don't create a method, or a class, or any other abstraction just so 
that it is reusable. You create abstractions so that it is easier to 
manipulate the software without breaking it.  Yes, if you have the same 
code in 3 places, pulling it into a method creates "reuse", but the 
reason you reuse the code is so that changes to it appear *everywhere* 
they should.  Otherwise copy and paste would be an acceptable method of 
code reuse. And its not.

My philosophy on designing software is make it correct, make it simple, 
make it pretty, make it fast.  Usually (but granted not always) if you 
start from the left, you'll end up at the right much easier than 
starting at the right and going left.

If making it simple or pretty involves pulling out a simple one-line 
method that isn't used but once, then so be it.  If pulling that method 
out makes it uglier, then I don't do it.

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

#15079

On Tue, 05 Jun 2012 10:51:13 -0700, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote:

>On 6/5/12 9:15 AM, Gene Wirchenko wrote:
>>       NO!  Pulling some code out to make it a method that is called
>> ONLY ONCE is what I object to.  (I might do it if there is
>> clearly-delineated functionality that could be useful again (but just
>> happens to be needed but once when it written)).  I will not do it for
>> some manifesto.
>
>Code re-usability is the great lie that has become the manifesto, not 
>pulling out a once-used method.
>
>You don't create a method, or a class, or any other abstraction just so 
>that it is reusable. You create abstractions so that it is easier to 
>manipulate the software without breaking it.  Yes, if you have the same 
>code in 3 places, pulling it into a method creates "reuse", but the 
>reason you reuse the code is so that changes to it appear *everywhere* 
>they should.  Otherwise copy and paste would be an acceptable method of 
>code reuse. And its not.
>
>My philosophy on designing software is make it correct, make it simple, 
>make it pretty, make it fast.  Usually (but granted not always) if you 
>start from the left, you'll end up at the right much easier than 
>starting at the right and going left.
>
>If making it simple or pretty involves pulling out a simple one-line 
>method that isn't used but once, then so be it.  If pulling that method 
>out makes it uglier, then I don't do it.

     We are in violent agreement.

Sincerely,

Gene Wirchenko

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

#15086

On 12-06-05 02:51 PM, Daniel Pitts wrote:
> On 6/5/12 9:15 AM, Gene Wirchenko wrote:
>> NO! Pulling some code out to make it a method that is called
>> ONLY ONCE is what I object to. (I might do it if there is
>> clearly-delineated functionality that could be useful again (but just
>> happens to be needed but once when it written)). I will not do it for
>> some manifesto.
>
> Code re-usability is the great lie that has become the manifesto, not
> pulling out a once-used method.
>
> You don't create a method, or a class, or any other abstraction just so
> that it is reusable. You create abstractions so that it is easier to
> manipulate the software without breaking it. Yes, if you have the same
> code in 3 places, pulling it into a method creates "reuse", but the
> reason you reuse the code is so that changes to it appear *everywhere*
> they should. Otherwise copy and paste would be an acceptable method of
> code reuse. And its not.
>
> My philosophy on designing software is make it correct, make it simple,
> make it pretty, make it fast. Usually (but granted not always) if you
> start from the left, you'll end up at the right much easier than
> starting at the right and going left.
>
> If making it simple or pretty involves pulling out a simple one-line
> method that isn't used but once, then so be it. If pulling that method
> out makes it uglier, then I don't do it.

We're pretty much in agreement. I don't think my reply to an earlier 
post of yours, sardonically characterizing yourself as an idiot, made it 
to this NG: in that reply I indicated that Gene actually captured my 
thinking well, and that you and I were discussing at cross-purposes.

My main objection to kneejerk "Extract As Method", to avoid things like 
loop labels (but really kneejerk for any reason), is maintenance - by me 
later, or by other people. I also agree that re-use isn't usually a 
major factor. For me it's maintenance, IOW readability. If I have to 
keep jumping, even with the aid of an IDE, from one spot to another to 
track down code chunks, it degrades my capability to put code in 
perspective, and it wastes my time.

On another note, copy and paste can be perfectly OK. It's not OK if you 
now have to maintain business rules or constants or suchlike in several 
spots, or if it's an intricate algorithm, but otherwise it can 
frequently be the right thing to do, again informed by maintenance 
considerations. Copy 'n' paste is wrong mainly when the people doing it 
don't understand what, and why, they are doing it.

AHS
-- 
Never interrupt your enemy when he is making a mistake.
--Napoleon

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

#15087

Arved Sandstrom wrote:
[snip]
> My main objection to kneejerk "Extract As Method", to avoid things like 
> loop labels (but really kneejerk for any reason), is maintenance - by me 
> later, or by other people. I also agree that re-use isn't usually a 
> major factor. For me it's maintenance, IOW readability. If I have to 
> keep jumping, even with the aid of an IDE, from one spot to another to 
> track down code chunks, it degrades my capability to put code in 
> perspective, and it wastes my time.
> 
> On another note, copy and paste can be perfectly OK. It's not OK if you 
> now have to maintain business rules or constants or suchlike in several 
> spots, or if it's an intricate algorithm, but otherwise it can 
> frequently be the right thing to do, again informed by maintenance 
> considerations. Copy 'n' paste is wrong mainly when the people doing it 
> don't understand what, and why, they are doing it.

+1

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

#15080

On 05.06.2012 18:15, Gene Wirchenko wrote:
> On Tue, 05 Jun 2012 07:31:44 +0200, Robert Klemme
> <shortcutter@googlemail.com>  wrote:

>       Which is often us so being nice to the maintenance programmer is
> being nice to oneself.

That's a nice side effect - and a motivating argument which helps the 
selfish. :-)

>       Besides the story paradigm, I also think in terms of program
> usefulness.  If a program is not very useful, one can write it pretty
> much any way one wants as the program is going to get tossed anyway.
> If it is useful, then it is going to stick around, and requirements
> have a way of changing so the program had better be maintainable.  It
> can also be difficult to tell whether a program will be useful so why
> not just write them all clearly?

I suspect often the answer to that question is: because the author did 
not understand the problem or the program or programming itself clearly. 
  The other big reason is carelessness, often increased by tight 
schedules.  Deadlines seem to make people nervous and trying to take 
short circuits.  But it will cost - sooner or later.

Kind regards

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web