Re: About java program.
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;
}
Why are you making it so complicated? Just do
private static boolean isStringYes(String str) {
return str.equals("yes");
}
Or, for NPE safety:
private static boolean isStringYes(String str) {
return "yes".equals(str);
}
Btw, I also changed the name because the method did not ask a question
at all.
Cheers
robert
To some extent I agree with you, Robert.
A little side note about the NPE-safe form of doing "equals": this can
sometimes bite because of the very liberal method signature. Just last
week I was doing some CXF+JAXB work with SOAP, and for a few hours I was
perplexed as to why a a path was not being taken. Anyone who has worked
with generated code for SOAP knows how verbose and encapsulated and
boilerplate it is; lots of commenting and good white space needed, and
copy & paste is to be avoided (albeit tempting).
Anyway, come to find out that I was doing a String equals (had to be
equals, not equalsIgnoreCase), and the argument was not a String but
through a typo an MXString. equals() of course happily accepted that and
always returned false.
That's not to say it wasn't my mistake, it was. But I've found that
equals() is a relatively fertile source of program defects.
With your method it's not a concern, you're controlling the type of the
parameter. But in wider expanses of code then it's important to nail
down that the 2 objects being compared are of the expected types. Code
reviews, maybe even an instanceof if correctness at this point is
essential (more so than we usually desire but often don't achieve :-))
For String in particular, I wouldn't actually mind if there was an
equals(String). In some cases I'll use String#compareTo(String) to
achieve that.
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.
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