Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > About java program.

Reply
Thread Tools

About java program.

 
 
Joerg Meier
Guest
Posts: n/a
 
      06-18-2013
On Mon, 17 Jun 2013 14:49:38 -0400, Eric Sosman wrote:

> On 6/17/2013 2:32 PM, Joerg Meier wrote:
>>[...]
>> Personally, I found your example considerably harder to read than the one
>> liner, as well as harder to read than what would have been my solution:
>>
>> private boolean askYesNoquestion (String str){
>> if(str.equals("yes"))
>> return true;
>>
>> return false;
>> }

> Or, for even greater clarity:


Obviously, in the case of booleans, this style is superfleous (and
especially in something this simple), but I was trying to demonstrate the
style, not write a better askYesNoquestion method.

However, as for returning true/false instead of expressions, while this
would be possible in this extremely simple example, the moment you have
more conditions, you end up either writing something hard to read with lots
of && and ||, or you end up with duplicate expressions, or you can go with
returning true/false.

I don't find "return (((x && y) || a && (z || v)) && c);" to be terribly
readable. "Exploding" that into a more verbose if/else structure often ends
up making code a lot more maintainable than the 'every extra letter must be
conserved' school of thinking.

Frankly, I'm surprised that even though it should be obvious that my code
was no more supposed to be production code for a method that simple,my

"if (x) return true"

faced so much more ridicule than lipskas

"boolean var; if (x) var = true; return var",

which is basically the same only even more verbose.

Liebe Gruesse,
Joerg

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      06-18-2013
On 6/18/2013 6:38 PM, Joerg Meier wrote:
>[...]
> Frankly, I'm surprised that even though it should be obvious that my code
> was no more supposed to be production code for a method that simple,my
>
> "if (x) return true"
>
> faced so much more ridicule than lipskas
>
> "boolean var; if (x) var = true; return var",
>
> which is basically the same only even more verbose.


Perhaps you attract more ridicule because your posts have a
wider readership than lipska's. That explains my reaction, at
any rate.

`if (bool) return true; else return false;' does have one
small advantage over `return bool;' in that it's easier to
plant a breakpoint on one branch but not on the other, if a
debugging session gets down to "This shouldn't be true, should
it? *Should* it?" Similarly, the style of assigning a
`result' variable throughout the body of a method and returning
it only at the end makes it easy to trap and trace "unusual"
values. In my experience these advantages are occasionally
worth the extra clutter -- but only occasionally. YMMV.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Arved Sandstrom
Guest
Posts: n/a
 
      06-19-2013
On 06/18/2013 07:56 PM, Eric Sosman wrote:
> On 6/18/2013 6:38 PM, Joerg Meier wrote:
>> [...]
>> Frankly, I'm surprised that even though it should be obvious that my code
>> was no more supposed to be production code for a method that simple,my
>>
>> "if (x) return true"
>>
>> faced so much more ridicule than lipskas
>>
>> "boolean var; if (x) var = true; return var",
>>
>> which is basically the same only even more verbose.

>
> Perhaps you attract more ridicule because your posts have a
> wider readership than lipska's. That explains my reaction, at
> any rate.
>
> `if (bool) return true; else return false;' does have one
> small advantage over `return bool;' in that it's easier to
> plant a breakpoint on one branch but not on the other, if a
> debugging session gets down to "This shouldn't be true, should
> it? *Should* it?" Similarly, the style of assigning a
> `result' variable throughout the body of a method and returning
> it only at the end makes it easy to trap and trace "unusual"
> values. In my experience these advantages are occasionally
> worth the extra clutter -- but only occasionally. YMMV.
>

I find the style of clearly declaring a result variable at the beginning
of a method often comes about because you have to declare the variable
anyway, because of try-catch and conditional blocks and so forth. So it
may as well get declared early.

I don't think it's a style to either decry or enthusiastically endorse.
It hardly introduces clutter, though.

AHS

--
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      06-19-2013
Eric Sosman <(E-Mail Removed)> writes:
> `if (bool) return true; else return false;' does have one
>small advantage over `return bool;' in that it's easier to
>plant a breakpoint on one branch but not on the other, if a
>debugging session gets down to "This shouldn't be true, should
>it? *Should* it?"


It is possible to still convert »return bool;« to this »if«
should this »if« ever be needed.

http://en.wikipedia.org/wiki/You_aren't_gonna_need_it

(In fact, I'd go so far as to convert it back to the smaller
form after a debugging session needing the longer form.)

Also, one must be careful not to »convert«

if( a )then b = true;

to

b = a;

because this will change the semantics in the case of !a,
but you all know this.

 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      06-19-2013
On 06/17/2013 07:36 PM, Joshua Cranmer šŸ§ wrote:
> On 6/17/2013 8:46 AM, lipska the kat wrote:
>> ... and what is your opinion of defensive coding?

>
> The term, as I understand it, refers to coding under the assumption that
> everyone who uses your API is a stupid idiot who can't follow your rules
> properly. The matter at hand here is basically a stylistic concern about
> which is mentally easier to follow, which falls under the category of
> "everyone has an opinion which is strongly held and won't be changed."

[ SNIP ]

Like I stated in a different post in this thread, the stupid idiot is
often you yourself (you as in impersonal "you"), since you wrote both
the calling code and the called code, and six months later you are
adapting the called code and can't remember the assumptions you made
previously because you had a whitebox view then, and hence you f**k up.

Defensive coding actually means that stupid idiots who "can't follow
your rules properly" don't mess up the called system. This has been
fundamental software engineering since forever.

But you're right, that's not the matter at hand, since I assume that you
yourself have a healthy appreciation for defensive coding.
>
> Style wars much? To me, personally, early-return is often valuable,
> especially in languages like C++ or Java which have useful constructs
> for handling post-call cleanup such as RAII or try-finally blocks. I'm
> going to stop short of saying I prefer early-return, since it is very
> much a decision that applies in a specific context, and these examples
> are all trying to apply a universally generic rule.

[ SNIP ]

Rule of thumb - if your average coder gets how the method does exits
quickly, then your style is fine. These days - basically the last 2
decades after programming became a commodity and most coders have
minimal formal background - I'm all for coding to the LCD. Which means
very defensive, and frequently not being elegant in favour of being obvious.

AHS
--
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift
 
Reply With Quote
 
Daniele Futtorovic
Guest
Posts: n/a
 
      06-19-2013
On 18/06/2013 22:50, Arved Sandstrom allegedly wrote:
> <snip />
> See my answer to Eric, all this is just ridiculing reasonable
> programming practices.
>
> Even given Robert's example where the NPE-safe equals() is wrapped in a
> method that constrains the type of object being compared to, it may not
> be expected or acceptable that the String is null. So perhaps you do
> want to check for that, maybe with Apache StringUtils.isBlank().
>
> Sure, the contrived absurd examples are retarded; so is the mockery of
> defensive programming. Oh well, there's a reason why most software
> projects still fail or go vastly over budget.


I'm all for defensive programming, but I think that there's a limit
where it can be on the verge of silliness, and that that limit has been
grazed here.

Less-than-bright programmers IMO cannot be a justification for crossing
that line; less-than-bright programmers have more ways to mess things up
than you could possibly ever guard against. "Do not underestimate the
ingenuity of complete fools", as the saying goes.

And for me, there is an additional aspect: if a piece of code does
something simple, something basic, then I will want it to be short, and
vice-versa. Verbosity of code, to me, should hold a first-glance
indication of the complexity of the algorithm. In other words: be terse
IFF it's basic, be verbose IFF it's not.

Perhaps your mileage does vary. No beef with that. Just throwing in my
two cents.

--
DF.
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      06-19-2013
On 06/19/2013 04:50 AM, lipska the kat wrote:
> On 18/06/13 21:50, Arved Sandstrom wrote:
>> On 06/17/2013 07:13 PM, Daniele Futtorovic wrote:
>>> On 17/06/2013 20:49, Eric Sosman allegedly wrote:
>>>> On 6/17/2013 2:32 PM, Joerg Meier wrote:
>>>>> [...]
>>>>> Personally, I found your example considerably harder to read than
>>>>> the one
>>>>> liner, as well as harder to read than what would have been my
>>>>> solution:
>>>>>
>>>>> private boolean askYesNoquestion (String str){
>>>>> if(str.equals("yes"))
>>>>> return true;
>>>>>
>>>>> return false;
>>>>> }
>>>>
>>>> Or, for even greater clarity:

>
> [snip drivel]
>
>> See my answer to Eric, all this is just ridiculing reasonable
>> programming practices.
>>
>> Even given Robert's example where the NPE-safe equals() is wrapped in a
>> method that constrains the type of object being compared to, it may not
>> be expected or acceptable that the String is null. So perhaps you do
>> want to check for that, maybe with Apache StringUtils.isBlank().
>>
>> Sure, the contrived absurd examples are retarded; so is the mockery of
>> defensive programming. Oh well, there's a reason why most software
>> projects still fail or go vastly over budget.

>
> Have you taken a 'sensible pill' by any chance?
>
> I find myself agreeing with you twice in the same thread ... is it me?
>
> IME one of the main reasons for failure is the attitude of certain team
> members that they are far too clever or far too important to the project
> to code responsibly. Their attitude is 'gosh, look at me I'm so clever
> that I can write code that only I can understand'
>
> I once knew a PhD who's attitude to commenting code was 'I don't need
> comments, I can read code'. Unfortunately this attitude carried over to
> his own code which was almost completely uncommented. When asked to
> comment his code his response was 'if you need comments then perhaps
> you'd better find something else to do' I fired his ass
>
> I think maybe a few of the responders to this thread could do with a
> lesson in basic code readability. Of course they would never admit it,
> they're obviously *way* to smart.
>
> lipska
>

I don't think I took a "sensible pill".

I fairly routinely encounter uninformed programmers, or prima donna
programmers. Or simply 9-5 M-F uninterested unionized programmers who
can't lose their job even if they do nothing. Over thirty years this
covers several hundred projects, teams and clients (in-depth knowledge
of those situations even if I wasn't actually directly involved), so I
don't think my observations are completely anecdotal or without merit.

The LCD is the average guy - and these days it's still overwhelmingly
guys - who isn't all that experienced (after all, every one of us once
had just 2 or 5 or 10 years of experience), who may not be formally
trained or may be badly educated, who may not be that motivated, and who
quite often regards programming as a way to pay the bills and not as a
craft nor as a delight.

If we stick to Java, the LCD doesn't quite get the difference between
reference and equals() comparisons, and when informed still needs
coaching to write a good equals(). The LCD often has never heard of
O(n), and far from being able to choose a good sort has in fact never
heard of most of the common sorting algorithms. Same goes for search, I
run across coders all the time that have never heard of fundamental
search strategies. This average programmer doesn't read blogs or
articles, doesn't know white box or black box testing theory, knows
almost nothing about JVM tuning [1], and is very weak on concurrency. So
forth and so on.

This is what *I* see in industry, in government and large corporate IT
projects. But maybe other folks have experienced idylls of nothing but
top-notch developers, and have started to get complacent. Dunno.

I don't know why there's even an argument about this, either defensive
coding or dumbing stuff down. In the real non-academic world you've got
to do it.

AHS

--
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift
 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      06-19-2013
On 19.06.2013 02:26, Arved Sandstrom wrote:

> I find the style of clearly declaring a result variable at the beginning
> of a method often comes about because you have to declare the variable
> anyway, because of try-catch and conditional blocks and so forth. So it
> may as well get declared early.


I try to declare in the smallest necessary scope. And I find myself
converting

boolean result = false;
try {
result = whatEver() || somethingElse();
}
catch (whatever...) {
no return or change of result
}
return result;

to

try {
return whatEver() || somethingElse();
}
catch (whatever...) {
no return or change of result
return false;
}

because I find that more readable. Variables are not a value in itself.
If they don't serve a purpose they should go away IMHO since they
decouple calculation of the value from usage. Of course, if you need
the same value multiple times then that warrants every variable. But
cases like the one above do not.

> I don't think it's a style to either decry or enthusiastically endorse.
> It hardly introduces clutter, though.


Right.

Cheers

robert



--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      06-19-2013
Arved Sandstrom wrote:
.. . .
> If we stick to Java, the LCD doesn't quite get the difference between
> reference and equals() comparisons, and when informed still needs
> coaching to write a good equals(). The LCD often has never heard of
> O(n), and far from being able to choose a good sort has in fact never
> heard of most of the common sorting algorithms. Same goes for search, I
> run across coders all the time that have never heard of fundamental
> search strategies. This average programmer doesn't read blogs or
> articles, doesn't know white box or black box testing theory, knows
> almost nothing about JVM tuning [1], and is very weak on concurrency. So
> forth and so on.


The sad thing is that your observations are accurate, and mine are similar.

The thing that makes me mad is that, despite these people's job titles,
they are not computer programmers. The things you describe are elementary
programming knowledge, things taught early in the process. For anyone to
collect a paycheck for that skill not to know these things is an insult.

They should be fired.

This is the sort of thing that makes me favor making computer programming
a formal engineering discipline. No one, at all anywhere, should tolerate someone
calling themselves a computer programmer who is that ignorant, incompetent and
uncommitted to the skills of their profession, let alone pay them for it.

--
Lew
 
Reply With Quote
 
Sven Köhler
Guest
Posts: n/a
 
      06-20-2013
Am 19.06.2013 22:20, schrieb Robert Klemme:
> boolean result = false;
> try {
> result = whatEver() || somethingElse();
> }
> catch (whatever...) {
> no return or change of result
> }


I would like to add, that I dislike the initialization of result in this
example. If result (for whatever reason) must be declared outside the
try-catch block, then please don't initialize it unless you plan on
doing something nasty. A nasty example would be that the try block sets
result to true midway and an exception in the second half doesn't change
the value of result to false for some weired reason.

The IMHO cleaner way is the following:

boolean result;
try {
result = whatEver() || somethingElse();
}
catch (whatever...) {
result = false;
}
// use result for whatever


And may all (ex-)C programmers in this group refrain from telling me
that not initializing variables is dangerous. This is Java, where the
compiler enforces initialization of variables on all code paths before
the first read-access to the variable.


Regards,
Sven
 
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


Similar Threads
Thread Thread Starter Forum Replies Last Post
I need your advices about C prg. Dogukan Bayraktar C Programming 76 06-16-2013 08:54 AM
Survey about Software Integration Martin Dias C Programming 0 04-29-2013 03:23 PM
Quesion about running a exe file in Python(Not enough memory) yuyaxuan0@gmail.com Python 5 04-26-2013 06:30 AM
silly question about Running a script from the command line A.Rock Python 0 04-10-2013 11:21 AM
newbie question about confusing exception handling in urllib cabbar@gmail.com Python 6 04-09-2013 07:11 PM



Advertisments