Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > hi

Reply
 
 
John W. Kennedy
Guest
Posts: n/a
 
      02-06-2007
Andrew Thompson wrote:
> On Feb 3, 11:22 pm, Martin Gregorie <(E-Mail Removed)> wrote:
>> Randolf Richardson wrote:
>>> This typically occurs because the reserved word "goto" isn't
>>> implemented. There are situations where "goto" would be very useful,
>>> such as:

>> I totally disagree. Assemblers need "goto" but no decent HLL does. That
>> goes for COBOL too and before you ask, yes I've written GOTO-less COBOL.

>
> Huh! I coded COBOL as well, and was not
> even aware it *had* a GOTO. (Seems I never
> saw the need to RTFM that far - even though
> it was my 'instruction manual' for the language.)


Post-1985, then, I imagine. Until then, it was possible to manhandle a
COBOL program into GOTO-less form, but it tended to be fragile.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
 
Reply With Quote
 
 
 
 
Martin Gregorie
Guest
Posts: n/a
 
      02-07-2007
Lew wrote:
> Gordon Beaton wrote:
>> I'm with you on this. I find that readability is improved if
>> declarations are collected at the start of the method, rather than
>> interspersed with code statements.

>
> I would accept your formatting in a code review if you said start of the
> block, rather than start of the method. Engineering rules trump
> formatting rules, so a "declare at the top" style should still yield to
> scope limitation.
>
> I distinguish between rules I follow and rules I want others to follow.
> I believe we all should limit the scope of variables, and I personally
> declare variables inline with use, but I wouldn't ask you to move your
> declarations in line.
>
> I happen to believe that readability is improved with variables declared
> near their use, diametrically opposite to your viewpoint. I also do not
> see any objective evidence that either of us is correct. I do see
> evidence that declaring variables in the narrowest scope provides
> stability and other engineering benefits.
>
> If I worked in a group that said "declare at the top of the block", I'd
> follow their rule except where engineering considerations override.
>

I'm happy with either approach and would go with either project standard
without argument. I used to declare variables at the top of a block in
the Algols and do like the scope limitation that provides: I guess that
too much C has stopped me using it. I must try harder.

The layout standard I've seen that I really don't like is the custom of
declaring class-level variables after the methods. Why reverse the
standard used inside blocks and methods other than sheer perversity?


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
 
 
 
Martin Gregorie
Guest
Posts: n/a
 
      02-07-2007
John W. Kennedy wrote:
> Andrew Thompson wrote:
>> On Feb 3, 11:22 pm, Martin Gregorie <(E-Mail Removed)> wrote:
>>> Randolf Richardson wrote:
>>>> This typically occurs because the reserved word "goto" isn't
>>>> implemented. There are situations where "goto" would be very useful,
>>>> such as:
>>> I totally disagree. Assemblers need "goto" but no decent HLL does. That
>>> goes for COBOL too and before you ask, yes I've written GOTO-less COBOL.

>>
>> Huh! I coded COBOL as well, and was not
>> even aware it *had* a GOTO. (Seems I never
>> saw the need to RTFM that far - even though
>> it was my 'instruction manual' for the language.)

>
> Post-1985, then, I imagine. Until then, it was possible to manhandle a
> COBOL program into GOTO-less form, but it tended to be fragile.
>

Indeed - and I wrote mostly COBOL and assembler before 1985 and mostly
other languages (C, Tal, PL/1) since. I suspect my COBOL habits are
permanently set by that experience.

The problem with goto-less COBOL was that not all conditional clauses
could have ELSE clauses. These implied conditionals were mandatory parts
part of some verbs, such as READ.....AT END....

COBOL-85 introduced ELSE clauses to the implied conditionals and in-line
PERFORM clauses, so now its easy to write:
PERFORM
READ A-FILE
AT END
MOVE "YES" TO A_FILE_EOF
ELSE
NOTE Process the record
END-IF
WHILE A-FILE-EOF NOT = "YES".

Prior to COBOL-85 writing it as goto-less code used to look like this:

PERFORM READ-INPUT-FILE WHILE A-FILE-EOF NOT = "YES".
...

READ-INPUT-FILE SECTION.
RIF-1.
READ A-FILE
AT END
MOVE "YES" TO A-FILE-EOF.
IF A-FILE-EOF NOT = "YES"
NOTE Process the record.
RIF-EXIT.
EXIT.

and arguably AT END MOVE 'YES' TO A-FILE-EOF GOTO RIF-EXIT would have
been a more robust solution than using the extra IF statement.

....and that's quite enough COBOL in a Java group. I now return you to
the normal language. I thank you for your time.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      02-08-2007
Martin Gregorie wrote:

> The layout standard I've seen that I really don't like is the custom of
> declaring class-level variables after the methods. Why reverse the
> standard used inside blocks and methods other than sheer perversity?


I used to do that; I have since reconsidered, but I can speak as a reformed
sinner...

I take it that you wouldn't want to see methods and fields interleaved (at
least, not except in very special cases) ? If so then either the fields go
first or they go last (or possibly both if you split public fields from other
fields). Now it's also fairly normal to want to put public members before
private ones[*]. So, fields, being private, don't go before the public
methods...

So they have to follow /all/ the methods. Simple!

([*] There's a well-regarded recommendation to do it the other way around for
C++, but that is C++-specific -- and I can't remember the justification
anyway.)

-- chris




 
Reply With Quote
 
nukleus
Guest
Posts: n/a
 
      02-08-2007
In article <(E-Mail Removed)>, Martin Gregorie
<(E-Mail Removed)> wrote:
>Lew wrote:
>> Gordon Beaton wrote:
>>> I'm with you on this. I find that readability is improved if
>>> declarations are collected at the start of the method, rather than
>>> interspersed with code statements.


Plus, and don't forget about this,
otherwise you'll end up spending lifetimes
to fix your program in case there is error.

If variables are declared at the top of the methods,
then all the error conditions and variable values
could be seen if you set a breakpoint in correct place
cause they won't go out of scope.

Especially if you have the exceptions in that method,
as if they are hit, you are COMPLETELY out to lunch,
and it would take you lifetimes to figure out WHY
that exception was hit if you are using declarations
deep inside the method. I even avoid using things like

for (int nInd = 0; nInd < limit; nInd++)

Instead, i do

int nInd;

for (int nInd = 0; nInd < limit; nInd++)
{
...
}

So, if i have an error condition inside for loop,
i can see which exact element caused it,
even if i am thrown out of the scope of the loop
by some exception.

>> I would accept your formatting in a code review


I absolutly hate "code reviews".
It simply means that there is some smart ass,
sitting on the top of a bunch of dummies,
telling them how screwed up they are,
and all it produces at the end
is guilt, leading to fear
to lose onse skin.

Instead of those stupid "code reviews",
you just work within a group and maintain
a constant feedback and exchange the ideas.

>> if you said start of the
>> block, rather than start of the method. Engineering rules trump
>> formatting rules, so a "declare at the top" style should still yield to
>> scope limitation.


I know plenty of those rules. But as far as end product goes,
those "rules" do not cover about the most subtle issues,
and especially the maintainability and future code modifications.
Long subject.

>> I distinguish between rules I follow and rules I want others to follow.


I know, I know.

:---}

It is called scitsophrenia.
In one situation you think like this,
and in another situation you think like that.

No wonder...

>> I believe we all should limit the scope of variables,


Yep. I like those "shoulds",
the byproducts of a rigid mind.

Now, on what basis should we limit the scope of variables?
What does it improve?
Not that I do not see what you mean,
but you need to be able to put the WHOLE thing
in perspective, and not only in terms of your
ideology, but the debugging process, code extensibility,
maintenance issues, code simplicity and readability
and all sorts of other things.

The rules of:

THOU SHALT LIMIT THE SCOPE OF YOUR VARIABLES
is simply incomplete of a statement.
There are no ifs and buts in it.
So, it is not programming.
It is totalitarian dictatorship
of black and white.

Programming is a pure logic,
as THAT is where all the intricacies come in.

If you use this black and white model,
your program will be the most oppressive thing there is.
To the user, to the programmer and the rest of them
mortals that come its way.

>> and I personally
>> declare variables inline with use,


Uhu.

And what happens if you hit an exception
during debugging?

Ever thought?

Can you look at those variables inside some loop
and see what EXACTLY happened?

How long will it take you to fix bugs with this approach?
How many times you would have to recompile
and how many source files you'd have to go thru
to see where is the error?

You see, looking at the source is not the same thing
as looking at the state of your program and variables
in RUN time.
Cause what you THOUGHT MUST be happening,
for some strange reason, do not happen.
And, usually, it is the simpliest things imaginable
that break your royal code.

>> but I wouldn't ask you to move your
>> declarations in line.


Which is about the most foolish thing to do.
Just recently, i was lazy enoug to declare my
variables in one lengthy operation where a number
of files are opened and, in some cases, a single
statement would cause the entire file load and parsing.
The error would happen after tens of minutes of operation
and, once the exception was hit, i did not have a SLIGHTEST
clue what exactly was the reason for that exception.

Once i moved the declaration on the most outside scope
of method, i could see that error within seconds.

Hows THAT for lesson in programming?

>> I happen to believe that readability is improved with variables declared
>> near their use, diametrically opposite to your viewpoint.


It all depends.
Sure, you are guaranteed a better memory dealocation
and sure, you may avoid some subtle bugs if you initialize
the variables on the most outside scope and, later on,
use them when they were not properly set in the inner levels,
and, instead of compile time errors, you get run time exceptions.
No question about it.
But this is just the BEGINNING of a story,
and not the end.

>>I also do not
>> see any objective evidence that either of us is correct.


Well, BOTH are correct
and both are wrong.

Because you need to specify ALL the conditions
and ALL the tradeoffs.

>> I do see
>> evidence that declaring variables in the narrowest scope provides
>> stability and other engineering benefits.


To general to even consider.
I doubt you have enough evidence for stability,
and i do not even attempt to figure out what those
"engineering benefits" are in specific terms.

>> If I worked in a group that said "declare at the top of the block", I'd
>> follow their rule except where engineering considerations override.


"declare at the top of the block" dictates
are no different then "use bracess this way" dictate.
You can hit me with a sledge hammer,
but i will still use the braces on the next line,
and i have a REASON for it, you see,
and the reason is simple enough to a mere mortal to comprehend.

If you use braces at the end of a line,
you can never be certain if you put them in the
right scope, especially in nested "if else" clauses.

>I'm happy with either approach and would go with either project standard
>without argument. I used to declare variables at the top of a block in
>the Algols and do like the scope limitation that provides: I guess that
>too much C has stopped me using it. I must try harder.


First of all, if you declare variables at the very beginning
of you method, you can review that code and see if some
variables and, therefore, some operations are simply overkill,
or you are doing some extra work on a method level that would
not have to be done if your code was more structured.

So, by sheer fact that you have some variables,
it indicates that you do some operations that NEED those
variables, and you can see that you might be using several
variable to carry the same exact information except in
a slightly different context, and so you can fix that code.

As far as memory management goes, it is true that the memory
deallocation may improve if you declare those variables
on the deepest scope possible as in that case,
the deallocation is pretty much automatic.

But again, that is just a beginning of the story,
and not the end.

>The layout standard I've seen that I really don't like is the custom of
>declaring class-level variables after the methods. Why reverse the
>standard used inside blocks and methods other than sheer perversity?


Well, i must be a pervert then.
I agree with you that it is better to move it in front,
generally speaking, but some methods have so much stuff
attached to them that it takes you quite some time
before you see the constructor code, which is about
the FIRST thing i want to see.

Then, after contructor code, i like to put the highest,
possibly thread level methods, such as start, stop, run,
Terminator (ever heard of such an animal), and things
like that.

Then, I'd like to see the main method, starting the
whole operation.

Then, after it, i like to see the more fine grained
methods.

And, about the LAST thing i want to see, is the even
handler code. That comes as just about the LAST thing
in that class, and the beauty of it, i know EXACTLY
where i can find it, even if i do not remember the
exact name of some variable or method,
which is an art on its own.

I can remember just about every single method or
variable in a pretty complex program, just because
of naming convention i use.

I can see what the methods do simply by looking
at the variable names those methods use.

And, the LAST thing i want to see is...

Tada!

The VARIABLES, in bulk.
But even there, they are all nicely sequenced
and the first in order come those of the most
outer scope and meaning, the MAJOR variables,
that could correspond to entire complex classes,
frames, etc.

Then comes the file level variables, file names,
handles, etc.

Then come the groups of related variables describing
some logically related operations or constructions.

Then comes the miscellaneous stuff, which i periodically
look at to see what kind of garbage is there
as there should be none on the first place as just about
all the variables should be decleared on more local
scope, otherwise you have a database consistency issue,
when several different methods access the same global,
and, in some cases, one hand does not know what the other
is doing.

As a general rule, I use as little globals as I can manage.
So far, my stuff runs, compiles, extends, and maintains
like a tank. Try to kill it. Even if you unplug the power
cord, in the middle of a file operation, I'll recover,
as long as operating system can recover the damaged file.

:--}



 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      02-08-2007
nukleus wrote:

> In article <(E-Mail Removed)>, Martin Gregorie
> <(E-Mail Removed)> wrote:
>>Lew wrote:
>>> Gordon Beaton wrote:
>>>> I'm with you on this. I find that readability is improved if
>>>> declarations are collected at the start of the method, rather than
>>>> interspersed with code statements.

>
> Plus, and don't forget about this,
> otherwise you'll end up spending lifetimes
> to fix your program in case there is error.
>
> If variables are declared at the top of the methods,
> then all the error conditions and variable values
> could be seen if you set a breakpoint in correct place
> cause they won't go out of scope.


If your methods are /so/ big
that this presents a problem to you
then I respectfully suggest
that your methods are /too/ big;
making them smaller
will simplify your [1] scope issue
and allow you to give useful names
(and a respectable meaning)
to the segments you extract
as well as
making your names properly local.

[1] I've had an issue with very-local-scoping
perhaps once in the past twenty years;
that was in C.

I spotted it
the next time I ran my ad-hoc tests
and fixed the issue in
about twenty seconds.

Of course anecdotes
are not data.

--
Chris "electric hedgehog" Dollin
There' no hortage of vowel on Uenet.

 
Reply With Quote
 
Oliver Wong
Guest
Posts: n/a
 
      02-08-2007

"Martin Gregorie" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> John W. Kennedy wrote:
>> Andrew Thompson wrote:
>>> On Feb 3, 11:22 pm, Martin Gregorie <(E-Mail Removed)> wrote:
>>>> Randolf Richardson wrote:
>>>>> This typically occurs because the reserved word "goto" isn't
>>>>> implemented. There are situations where "goto" would be very useful,
>>>>> such as:
>>>> I totally disagree. Assemblers need "goto" but no decent HLL does. That
>>>> goes for COBOL too and before you ask, yes I've written GOTO-less
>>>> COBOL.
>>>
>>> Huh! I coded COBOL as well, and was not
>>> even aware it *had* a GOTO. (Seems I never
>>> saw the need to RTFM that far - even though
>>> it was my 'instruction manual' for the language.)

>>
>> Post-1985, then, I imagine. Until then, it was possible to manhandle a
>> COBOL program into GOTO-less form, but it tended to be fragile.
>>

> Indeed - and I wrote mostly COBOL and assembler before 1985 and mostly
> other languages (C, Tal, PL/1) since. I suspect my COBOL habits are
> permanently set by that experience.
>
> The problem with goto-less COBOL was that not all conditional clauses
> could have ELSE clauses. These implied conditionals were mandatory parts
> part of some verbs, such as READ.....AT END....
>
> COBOL-85 introduced ELSE clauses to the implied conditionals and in-line
> PERFORM clauses, so now its easy to write:
> PERFORM
> READ A-FILE
> AT END
> MOVE "YES" TO A_FILE_EOF
> ELSE
> NOTE Process the record
> END-IF
> WHILE A-FILE-EOF NOT = "YES".
>
> Prior to COBOL-85 writing it as goto-less code used to look like this:
>
> PERFORM READ-INPUT-FILE WHILE A-FILE-EOF NOT = "YES".
> ...
>
> READ-INPUT-FILE SECTION.
> RIF-1.
> READ A-FILE
> AT END
> MOVE "YES" TO A-FILE-EOF.
> IF A-FILE-EOF NOT = "YES"
> NOTE Process the record.
> RIF-EXIT.
> EXIT.
>
> and arguably AT END MOVE 'YES' TO A-FILE-EOF GOTO RIF-EXIT would have been
> a more robust solution than using the extra IF statement.


What about:

PERFORM
READ A-FILE
AT END
MOVE "YES" TO A_FILE_EOF
NOT AT END
NOTE Process the record
END READ
WHILE A-FILE-EOF NOT = "YES".

?

I'm not sure how "standard" this is, but I believe this works on both Liant
RM/COBOL and ILE COBOL400.

- Oliver


 
Reply With Quote
 
nukleus
Guest
Posts: n/a
 
      02-08-2007
In article <eqfj2h$4o8$(E-Mail Removed)>, Chris Dollin
<(E-Mail Removed)> wrote:
>nukleus wrote:
>
>> In article <(E-Mail Removed)>, Martin Gregorie
>> <(E-Mail Removed)> wrote:
>>>Lew wrote:
>>>> Gordon Beaton wrote:
>>>>> I'm with you on this. I find that readability is improved if
>>>>> declarations are collected at the start of the method, rather than
>>>>> interspersed with code statements.

>>
>> Plus, and don't forget about this,
>> otherwise you'll end up spending lifetimes
>> to fix your program in case there is error.
>>
>> If variables are declared at the top of the methods,
>> then all the error conditions and variable values
>> could be seen if you set a breakpoint in correct place
>> cause they won't go out of scope.

>
>If your methods are /so/ big
>that this presents a problem to you
>then I respectfully suggest
>that your methods are /too/ big;
>making them smaller


Agreed. But, in case of code I am dealing with,
it is easier said then done.
I did try get get rid of as much stuff,
as I could manage, but there are some more
subtle issues involved.
ANY class is guaranteed to be aware of the
main class and so it can ask from main just
about any information out there. But if your
move some code to their own classes, you simply
add at least one more level of idirection and
a number of get/put methods.

Sure, we can argue about it this way or that,
and if i wrote this code from scratch, i'd
probably use the entirely different approach
and use state machine an fully asynchronous
operation. Unfortunately, to rewrite the code
to do that is just about as good as scrapping
the whole thing and starting from scratch.
Too much work to be done and too lil time to do it.

>will simplify your [1] scope issue
>and allow you to give useful names
>(and a respectable meaning)
>to the segments you extract
>as well as
>making your names properly local.


Agreed.

>[1] I've had an issue with very-local-scoping
> perhaps once in the past twenty years;
> that was in C.
>
> I spotted it
> the next time I ran my ad-hoc tests
> and fixed the issue in
> about twenty seconds.
>
> Of course anecdotes
> are not data.


Yep, and I know EXACTLY what I am talking about.
Played with this scope thing in just about
any way imaginable. In some simpliest cases i do
use the most local scope possible, usually at the
point of initial prototyping. But then I look at the
code and try to move all declarations as high up
as I can manage because I know all too well, that
when I have some bug and a breakpoint hit or exception
triggered, about the last thing i want to see
is my variables getting out of scope.
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      02-09-2007
Lew wrote:
>>> I distinguish between rules I follow and rules I want others to follow.


nukleus wrote:
> I know, I know.
>
> :---}
>
> It is called scitsophrenia.
> In one situation you think like this,
> and in another situation you think like that.


The correct spelling is "schizophrenia" and it refers to a psychosis whereby
the patient suffers hallucinations, delusions, inappropriate affect or other
symptoms of being completely out of touch with reality. You may be referring
to so-called "split personality", which is not schizophrenia but a completely
different disorder.

<http://en.wikipedia.org/wiki/Schizophrenia>

A stereotypic type of schizophrenia is paranoid schizophrenia, wherein the
sufferer imagines themself the object of persecution, ridicule, oppression or
other hostile behavior when no such behavior actually exists.

Lew said:
>>> and I personally
>>> >> declare variables inline with use,


nukleus wrote:
> Uhu.
>
> And what happens if you hit an exception
> during debugging?
>
> Ever thought?


Of course.

> Can you look at those variables inside some loop
> and see what EXACTLY happened?


Yes.

> How long will it take you to fix bugs with this approach?


Not too long.

> How many times you would have to recompile
> and how many source files you'd have to go thru
> to see where is the error?


Once, after I fix the bug.

> You see, looking at the source is not the same thing
> as looking at the state of your program and variables
> in RUN time.
> Cause what you THOUGHT MUST be happening,
> for some strange reason, do not happen.
> And, usually, it is the simpliest things imaginable
> that break your royal code.


That is why I use exception handling, logging and debuggers.

Lew said:
>>> I believe we all should limit the scope of variables,


nukleus wrote:
> Yep. I like those "shoulds",
> the byproducts of a rigid mind.


Or of one that has read Joshua Bloch on this subject (/Effective Java/) and
others, and has understood the benefits of the approach.

The /ad hominem/ attack does not go far to support the argument.

- Lew
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      02-09-2007
nukleus wrote:
> Yep, and I know EXACTLY what I am talking about.
> Played with this scope thing in just about
> any way imaginable. In some simpliest cases i do
> use the most local scope possible, usually at the
> point of initial prototyping. But then I look at the
> code and try to move all declarations as high up
> as I can manage because I know all too well, that
> when I have some bug and a breakpoint hit or exception
> triggered, about the last thing i want to see
> is my variables getting out of scope.


Or lingering past their useful scope and causing trouble thereby.

- Lew
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments