Re: About java program.
On 06/17/2013 10:46 AM, lipska the kat wrote:
On 17/06/13 13:49, Arved Sandstrom wrote:
On 06/16/2013 12:28 PM, Robert Klemme wrote:
On 16.06.2013 15:21, lipska the kat wrote:
On 16/06/13 00:12, Robert Klemme wrote:
On 15.06.2013 22:38, rajbhaumik@gmail.com wrote:
import acm.program.*;
public class askYesNoQuestion extends ConsoleProgram {
public void run(){
String str=readLine("Would you like instructions");
println(askYesNoquestion(str));
}
7. private boolean askYesNoquestion (String str){
if(str.equals("yes"))return true;
if(str.equals("no")) return false;
}
}
the false is that , the program cannot be executed, because no 7
said, this method must return a type of boolean.
One possible solution (not compiled or tested)
private boolean askYesNoquestion (String str){
boolean response = false;
if(str.equals("yes")){
response = true;
}
return response;
}
[snip]
To the original point, I agree to an extent. But the actual idiom that
lipska used is not bad in general, if you're used to single return. It's
sort of like *always* providing braces for conditionals, even for one
liners, defensive coding in part, but also adhering to personal coding
style.
... and what is your opinion of defensive coding?
Not far different from yours, apparently.
Anyone who has ever written software to interact with a user via a
device interface knows (or should know) that defensive coding is de-riguer.
If you don't want the device to crash every time someone does something
unexpected you need to anticipate no only the unexpected but the
unanticipated. There is *no* room for error.
This discipline is hard to learn and once learned even harder to
un-learn. This is why I don't like things like
return str.equals("yes");
It's lazy coding and harder to understand than my example and yes, I
realize that it's only a one liner but the next stage in the
'development' of this style is
if(something){
return something;
}
else if(something else){
return something else;
}
else{
return some other value
}
It is much easier to understand and debug
the following
type var;
if(something){
var = something;
}
else if(something else){
var = something else;
}
else{
var = some other value
}
return var;
If I was doing a proper job and not just providing a simple example I
would have had a pre-condition on the method *and* exception handling
*and* braces around every conditional, even one liners,
*and* a fallback position if the operation was mission critical. So yes,
it's my personal style learned from painful experience.
Thank you for understanding
lipska
Generally speaking all of this boils down to one thing: errors happen
when the same developer - you, me, anyone - has white-box knowledge of,
and maybe responsibility for, both called *and* calling code. This
extends even to method lexical scope where a developer may write some
stuff that makes assumptions about his or her own code in the same
method 50 lines previous.
I daresay that this state of affairs is the norm. Sure, a whole bunch of
developers work on NASA or defense or avionics or Big Healthcare type
projects where you've got a great deal of imposed rigor. But very likely
most developers own a whole bunch of code, and I'm sure that a large
number of us write entire apps. For example, as a software consultant I
often do analyze, design and code entire applications.
So, given this, it's necessary to be somewhat schizophrenic - when
working on method X in class A, and it's called by method Y in class B
and method Z in class C, and you are writing *all* of them, you need to
wear 3 hats. And by extension N hats as you implement the entire app,
and even more because you're also doing design and analysis.
God forbid that the developer also does the functional and integration
and system testing, but this is not rare. But let's ignore that aspect
of real life. :-)
If there actually is a good sized team the same considerations apply.
The nature of the beast these days is that often developers have
visibility into calling code that they don't have responsibility for,
because they do git or svn or hg, and they inevitably see way more than
they ought to.
I've rarely seen it done, because it adds substantial cost, but a better
approach would be to have each developer assigned (a) method(s) in a
class just write the class, and also be given time to write necessary
scaffolding in the form of tests that exercises their code. They never
see the complete codebase. The advantage of this is that they write to a
written design spec and not to knowledge of other code, and that they
have also necessarily written useful tests.
Robert's method, the NPE-safe one that also types the method parameter,
is not objectionable to me precisely because the equals is encapsulated
in a method that constrains the type. Trivial methods of this sort are
quite handy as private methods and make the code more robust, since
equals() by itself is too Wild West.
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