|
Posted by John Bokma on March 21, 2008, 1:30 pm
Please log in for more thread options
> John Bokma wrote:
>
>> Instead of rules I prefer to ask myself the following questions:
>>
>> 1) can I understand my own code next month without effort (can I
>> after
>> one year)
>> 2) can a peer do the same?
>
> I have to read my own, and others, code from 15+ years ago.
>
> I can assure you that in a loop a statement of:
>
> goto DONE_THIS:
>
> and a DONE_THIS label at the end of a loop is much easier to follow
> than a last, break or continue.
I think that has also to do with what you're used to. with last, next,
etc. the direction is in the keyword. With goto, you have to pick a clear
label. I see no difference between:
last DOING_THIS;
goto DONE_THIS;
--
John
http://johnbokma.com/
|
|
Posted by Big and Blue on March 23, 2008, 9:53 pm
Please log in for more thread options
Various people wrote various parts of:
>
> I think that has also to do with what you're used to. with last, next,
> etc. the direction is in the keyword.
The direction might be, but the location isn't if you don't use a label (and
with thise you don't need to). At least goto's always have a label.
> With goto, you have to pick a clear
> label. I see no difference between:
>
> last DOING_THIS;
>
> goto DONE_THIS;
Agreed, but there can be a difference between:
last;
and
got to DONE_THIS;
and...
> more readable than
>
> while (<>) {
> some_code();
> if ($x) {
> more_code();
> if ($y) {
> even_more_code();
> if ($z) {
> if_all_goes_well();
> }
> }
> }
> }
a) I would never use tabs (which is what are there in the copy I received) -
they are an abomination, since they can mean different things to different
people, and hence any alignment they produce is fragile
b) as for the code, that's why elsif exists:
while (<>) {
some_code();
if ($x) {
more_code();
}
elsif ($y) {
even_more_code();
}
elsif ($z) {
if_all_goes_well();
}
}
--
Just because I've written it doesn't mean that
either you or I have to believe it.
|
|
Posted by szr on March 24, 2008, 1:46 am
Please log in for more thread options Big and Blue wrote:
[...]
>
>> With goto, you have to pick a clear
>> label. I see no difference between:
>>
>> last DOING_THIS;
>>
>> goto DONE_THIS;
>
> Agreed, but there can be a difference between:
>
> last;
> and
> got to DONE_THIS;
>
I believe the comparison for goto vs. next/last/redo is concerned where
the latters use labels; to me that's where they are most similar to
'goto'.
[...]
> a) I would never use tabs (which is what are there in the copy I
> received) - they are an abomination, since they can mean different
> things to different people, and hence any alignment they produce is
> fragile
Indeed, especially in a widely used plain-text medium such as UseNet and
even plain-text email. Tabs can easily differ in size depending on the
platform, editor, the font, and the font size, and it gets even messier
if you compare news readers that use a fixed-width font (I think
majority still do) vs. ones that use a proportional font. At least for
UseNet, spaces should always be used instead of raw tabs.
Many readers (like the one I'm using right now), when composing, will
yields a certain about of spaces, predefined in the preferences, when
you hit the TAB key.
> b) as for the code, that's why elsif exists:
>
> while (<>) {
> some_code();
> if ($x) {
> more_code();
> }
> elsif ($y) {
> even_more_code();
> }
> elsif ($z) {
> if_all_goes_well();
> }
> }
Actually it would have to read like:
while (<>) {
some_code();
if ($x) {
more_code();
}
elsif ($x && $y) {
even_more_code();
}
elsif ($x && $y && $z) {
if_all_goes_well();
}
}
in order to equate to:
while (<>) {
some_code();
if ($x) {
more_code();
if ($y) {
even_more_code();
if ($z) {
if_all_goes_well();
}
}
}
}
--
szr
|
|
Posted by Peter J. Holzer on March 24, 2008, 7:50 am
Please log in for more thread options > Big and Blue wrote:
>> b) as for the code, that's why elsif exists:
>>
>> while (<>) {
>> some_code();
>> if ($x) {
>> more_code();
>> }
>> elsif ($y) {
>> even_more_code();
>> }
>> elsif ($z) {
>> if_all_goes_well();
>> }
>> }
>
> Actually it would have to read like:
>
> while (<>) {
> some_code();
> if ($x) {
> more_code();
> }
> elsif ($x && $y) {
> even_more_code();
> }
> elsif ($x && $y && $z) {
> if_all_goes_well();
> }
> }
>
> in order to equate to:
>
> while (<>) {
> some_code();
> if ($x) {
> more_code();
> if ($y) {
> even_more_code();
> if ($z) {
> if_all_goes_well();
> }
> }
> }
> }
>
Nope. Anyone up for a third try?
hp
>
|
|
Posted by Willem on March 24, 2008, 8:07 am
Please log in for more thread options Peter wrote:
)> Actually it would have to read like:
)>
)> while (<>) {
)> some_code();
)> if ($x) {
)> more_code();
)> }
)> elsif ($x && $y) {
)> even_more_code();
)> }
)> elsif ($x && $y && $z) {
)> if_all_goes_well();
)> }
)> }
)>
)> in order to equate to:
)>
)> while (<>) {
)> some_code();
)> if ($x) {
)> more_code();
)> if ($y) {
)> even_more_code();
)> if ($z) {
)> if_all_goes_well();
)> }
)> }
)> }
)> }
)>
)
) Nope. Anyone up for a third try?
)
) hp
Assuming more_code and even_more_code have no effect on $y and $z:
(Which is an unwarranted assumption, by the way)
while (<>) {
some_code();
if ($x && not $y) {
more_code();
}
elsif ($x && not $z) {
more_code();
even_more_code();
}
elsif ($x) {
more_code();
even_more_code();
if_all_goes_well();
}
}
Which is quite silly, of course.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
|
| Similar Threads | Posted | | help me pass argument to the subroutine and then return the value from that subroutine to another. | October 14, 2006, 1:35 am |
| A subroutine for gcd | July 17, 2006, 9:38 am |
| subroutine | July 20, 2006, 5:36 pm |
| "Undefined subroutine" | November 21, 2004, 8:48 pm |
| How to tell if a subroutine arg is a constant | February 24, 2005, 9:13 am |
| Subroutine Function | March 3, 2005, 5:14 pm |
| subroutine explanation | April 22, 2005, 8:40 am |
| problam in subroutine? | December 5, 2005, 1:40 pm |
| calling subroutine | January 3, 2006, 6:35 pm |
| subroutine doesn't seem to run after calling it. | May 9, 2006, 4:04 pm |
|