About java program.

[Daniele Futtorovic]

On 22/06/13 18:25, Daniele Futtorovic wrote:
The aforementioned is mitigated in code that is internal to a
component (in the spirit of encapsulation, code ought to be divided
into components such that the density of interrelation of code
within a component is always strictly greater than that of
interrelation of code in different components).

You mean it should be cohesive (the code in a component), still, why
use one word when fifty will do.

as you say.

"verbosity is but a pathetic front to mask either their lack of
professionalism" [sic]

No, I did not simply say it should be cohesive. If you want to
substitute "cohesiveness" for "density of interrelation" (which is fair
enough), I said it should be more cohesive within the component than
between components, and that this is what characterises something as
being a component. Not the same thing.

But still, assuming it were the same thing for a moment (which, again,
it is not by a wide stretch), do you really think that completely
twisting my words, under the guise of quoting me, to proceed to
advocate, for a natural and hence inexact language, a practice which you
rebuke me for advocating for a computer and hence exact language is
going to induce me to take you seriously?

What is this obsession that people on this group seem to have with being
taken seriously? I couldn't care less if you 'take me seriously' I have
nothing to prove to you or anyone else so please don't waste any more
time on 'taking me seriously'. When you come out with complete bollocks
like ...

"verbosity is but a pathetic front to mask either their lack of
professionalism" [sic]

Then expect me to react. It's nothing personal fercrissakes.

To conclude this discussion (as I am not inclined to debate with someone
I can't take seriously), let me point out once more that that quote is
the product of your very imagination; for by omitting the quotes around
the word "verbosity" and by omitting the context from what I originally
wrote, you have entirely distorted the original meaning of what I wrote,
to wit, that to someone who argues they should leave out essential
functionality out of their code because that essential functionality
would make their code too verbose, "verbose" (that is, the argument of
verbosity) is but a front to mask their lack of professionalism, and not
what verbosity is actually about. You'd have to read that to which I was
responding, viz. Arved's posting, to understand why I was making that
distinction.

 

[Gene Wirchenko]

On Fri, 21 Jun 2013 21:14:39 +0000 (UTC), Martin Gregorie

[snip]

Consequently, you didn't bother with storing the century unless you
really had to, e.g. you had people on file with birthdays in the previous
century.

In alt.folklore.computers, I have read posts by people who have
stated that there wre programs that had only one digit for year and
when the 1970's started, the report programs had to be updated.

Sincerely,

Gene Wirchenko

 

[Arne Vajhøj]

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, (e-mail address removed) 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?

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");

Why?

Your code and this code has the exact same potential for problems!?!?

It's lazy coding and harder to understand than my example

Not is is not. It has less elements to understand.

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

Exception handling is rarely a good thing to try ay such low level -
and especially not a NPE.

*and* braces around every conditional, even one liners,

You already had.

Arne

 

[Arne Vajhøj]

[...]
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:

private boolean askYesNoquestion(String str) {
boolean yes;
boolean no;
if (str != null && str.equals("yes")) {
yes = true;
no = false;
} else if (str != null && str.equals("no")) {
no = true;
yes = false;
} else {
yes = no = false;
}
return (no != true && yes != false) == true;
}

(If we put our minds to it, I bet we can turn the one-liner
into an entire class hierarchy with runtime-selected plug-in
provider implementations!)

We can joke about it, but the one-liner has problems, especially if not
wrapped in a method like Robert did. I've seen exactly that one-liner
cause dozens of defects over the past 15 years of me doing Java.

Really.

Could you give an example of a problem that would impact the
one liner, but not impact the four liner it replaced?

Arne

 

[Arne Vajhøj]

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:

private boolean askYesNoquestion(String str) {
boolean yes;
boolean no;
if (str != null && str.equals("yes")) {
yes = true;
no = false;
} else if (str != null && str.equals("no")) {
no = true;
yes = false;
} else {
yes = no = false;
}
return (no != true && yes != false) == true;
}

Call me sceptical, but I'm sceptical: I find that one-line return
statement kinda confusing. For more clarity, it should be encapsulated:

public static boolean isTrue( boolean b ){
boolean ret;
if( b == true ){
ret = true;
}
else {
ret = false;
}

return ret;
}

private boolean askYesNoquestion(String str){
...
return isTrue( ! isTrue(no) && isTrue(yes) );
}

Better, dontcha think?

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 don't think anyone is arguing against defensive programming - I
think some people are arguing against not necessary variables
and if statements.

Arne

 

[Arne Vajhøj]

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.

but that's not what I wrote, and yes, I understand you were generalizing

What I actually wrote was

boolean response = false;
if(str.equals("yes")){
response = true;
}
return response;

let's analyze this (lack of error handling notwithstanding)

first we give a sensible name to the variable,
one that reflects it's existential imperative.

then we have our conditional expression. This is surrounded by braces,
always. If not you get something like this

if(str.equals("yes"))
return true;
return false;

Look familiar?

Finally we have our single return statement.

There is more to coding defensively than simply handling Exceptions

Defensive coding is also about making code easy to read, explicit,
unambiguous down the line and not 'too clever by half' so that future
maintenance is made impossible or at least very expensive.

The above has nothing to do with defensive coding. It does
not protect against anything that the simple:

return str.equals("yes");

does not protect against.

And it is not more readable. It takes longer time
to read.

The one-liner consist of 2 items (evaluate equals, return).

The long version has the same 2 items plus 2 more items
(variable declaration, if statement).

Arne

 

[Robert Klemme]

On 05/07/13 04:11, Arne Vajhøj wrote:

For goodness sake *read the post*

I said 'lack of error handling notwithstanding'

Do you understand what that means?

Do you want an example of defensive coding?

READ THIS FIRST
This is an *example* ... got that, good.

Funny thing is that people will only see in an example what is presented
in the example. So if there is an example which leaves place for
specific error handling and that error handling is not included people
won't see it. They just see a method with unnecessary complexity.

Maybe you'll say it's not easy to pick a good example. But examples are
there for a reason: they are used as tools to communicate something. If
they fail to do that they should be improved or left out.

and no, I haven't compiled it and no, I wouldn't normally hard code
messages in this way (jeez)

Now then

private boolean askYesNoquestion (String str) throws BadArgumentException{

boolean result = false;

if(null == str){
logger.log("Argument is null");
throw new BadArgumentException("Argument is null");
}
else{
if(str.equals("yes")){
result = true;
}
else if(!str.equals("no")){
logger.log("Incorrect Argument, argument is " + str);
throw new BadArgumentException("argument is " + str);
}
}
return result;
}

This is *one* way of doing it

Overkill ... no, defensive yes.

This example demonstrates what I will call bad practice: the exception
is thrown so the calling code can decide how to handle the error. It
may actually be that the caller can perfectly deal with that situation
and proceed normally. Method askYesNoquestion() cannot know this. But
because the method does the logging itself you'll end up seeing messages
in a log file for things which are not noteworthy. I say, either log
and deal with the error locally OR throw an exception containing a
meaningful message - but not both. That is misleading.

Cheers

robert

 

[Arne Vajhøj]

On 18/06/13 23:38, Joerg Meier wrote:
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.

but that's not what I wrote, and yes, I understand you were generalizing

What I actually wrote was

boolean response = false;
if(str.equals("yes")){
response = true;
}
return response;

let's analyze this (lack of error handling notwithstanding)

first we give a sensible name to the variable,
one that reflects it's existential imperative.

then we have our conditional expression. This is surrounded by braces,
always. If not you get something like this

if(str.equals("yes"))
return true;
return false;

Look familiar?

Finally we have our single return statement.

There is more to coding defensively than simply handling Exceptions

Defensive coding is also about making code easy to read, explicit,
unambiguous down the line and not 'too clever by half' so that future
maintenance is made impossible or at least very expensive.

The above has nothing to do with defensive coding. It does
not protect against anything that the simple:

For goodness sake *read the post*

I said 'lack of error handling notwithstanding'

Do you understand what that means?

Actually - yes.

But apparently you do not since you started arguing for your
code referring to defensive coding.

Arne

 

[Arne Vajhøj]

This example demonstrates what I will call bad practice: the exception
is thrown so the calling code can decide how to handle the error. It
may actually be that the caller can perfectly deal with that situation
and proceed normally. Method askYesNoquestion() cannot know this. But
because the method does the logging itself you'll end up seeing messages
in a log file for things which are not noteworthy. I say, either log
and deal with the error locally OR throw an exception containing a
meaningful message - but not both. That is misleading.

I do not agree with the last point.

If we look at the matrix:

caller logs caller do not log
log insignificant extra log entry fine
not log fine big problem troubleshooting

then it seems obvious to me to log anyway. Worst case by logging
is not nearly as bad as worst case not logging.

Arne

 

[Robert Klemme]

I do not agree with the last point.

If we look at the matrix:

caller logs caller do not log
log insignificant extra log entry fine

I do not agree to the "insignificant".

not log fine big problem troubleshooting

then it seems obvious to me to log anyway. Worst case by logging
is not nearly as bad as worst case not logging.

Maybe I haven't made myself clear enough: it is the task of the writer
of the calling code to decide whether the exception is a problem or not.
This decision cannot be done by the author of this method. Presumably
this is a low level method which is invoked from many different places
and so some may be able to handle the exception while some may not.
Since a RuntimeException (NPE is one) will be likely caught somewhere
high up the call chain and logged there (usually with the stack trace)
debugging should not be too difficult. If on the other hand you need to
wade through tons of log messages which do not signal an error then
debugging is also harmed. Not to mention the additional IO overhead for
all the superfluous log messages.

Cheers

robert

 

[Robert Klemme]

Frankly I think you are missing the whole point of defensive programming.

You yourself said

"It may actually be that the caller can perfectly deal with that
situation..."

The important word here is *may* ... what happens if the caller decides
to ignore the exception, or maybe handle it without recording the
reason. What are you left with ...

Well, you can forget the logging on *any* level of the application.
There is no really a difference between asking the author of this method
to do proper error handling or asking the author of some other code to
do it.

The example is trivial I agree but the concept is sound.

If you do that kind of logging in all sorts of methods you'll end up
with extreme volumes of logfiles that make it hard to detect real bugs
and cost significant IO.

... and who says these things are not *noteworthy*. If you are
programming defensively then *everything* is noteworthy.

For me "defensive programming" in this example means to check arguments
and throw NPE or IllegalArgumentException if the data passed into the
method violates the specified (e.g. in JavaDoc) contract. Nothing more.
Errors will show up. If the caller does not handle exceptions
properly then the exception will show up somewhere up the call stack
where it's logged or presented to the user. Easy to find bugs then.

IMHO it is bad practice *not* to log the error at the point of origin.

The point is: you do not know whether it _is_ an error inside this
method. You know arguments violate the contract, but you do not know
whether that poses a problem for the program. Hence: throw an exception
and be done.

There's an old adage in this business "You can never have too much data"
This is especially true when programing defensively.

I disagree.

Cheers

robert

 

[Eric Sosman]

[...]
Well, you can forget the logging on *any* level of the application.
There is no really a difference between asking the author of this method
to do proper error handling or asking the author of some other code to
do it.

The caller has more context. When Integer.parseInt() is
unable to make sense of the input string, it has no way of knowing
whether the failure is fatal, unusual, or expected. Do you think
it should log all such failures in addition to throwing up?

 

[Arne Vajhøj]

I do not agree to the "insignificant".

It is just an extra log entry.

Whether the log file is 100 MB or 110 MB does not really change anything.

Maybe I haven't made myself clear enough: it is the task of the writer
of the calling code to decide whether the exception is a problem or not.

Yes. That is somewhat orthogonal to whether to log or not.

This decision cannot be done by the author of this method. Presumably
this is a low level method which is invoked from many different places
and so some may be able to handle the exception while some may not.
Since a RuntimeException (NPE is one) will be likely caught somewhere
high up the call chain and logged there (usually with the stack trace)
debugging should not be too difficult. If on the other hand you need to
wade through tons of log messages which do not signal an error then
debugging is also harmed. Not to mention the additional IO overhead for
all the superfluous log messages.

Assuming that somebody else will do the right thing show good faith
in mankind but is still not a recommended way to design software.

Developers are humans and humans make mistakes. Don't assume that other
developers always do what they are supposed to do. They may do it 99% of
cases but in 1% of cases they do not get it right - bad day or something.

Arne

 

[Arne Vajhøj]

Well, you can forget the logging on *any* level of the application.
There is no really a difference between asking the author of this method
to do proper error handling or asking the author of some other code to
do it.


If you do that kind of logging in all sorts of methods you'll end up
with extreme volumes of logfiles that make it hard to detect real bugs
and cost significant IO.

In all my years working with log4j log files I have never felt that
it was a problem with too much logged but often cursed that they did
not log exactly what I needed.

For anything except the most trivial apps the log files are too big
to just read top down. You need to use tools: editor find, grep,
special log tools, whatever.

And then it really doe snot matter of it is 1 MB, 10 MB, 100 MB or 1 GB.

And log files are sequentially written text files. Logging a MB per hour
has very little performance impact today.

The point is: you do not know whether it _is_ an error inside this
method. You know arguments violate the contract, but you do not know
whether that poses a problem for the program.
Correct.

Hence: throw an exception
and be done.

No.

Logging is not intended only to be used for errors.

If we look at log4j log levels:

fatal
error
warn
info
debug
trace

then I agree that because we do not know if it is an error, then
we should not use the first 2 levels, but that leaves 4 levels
as potential candidates for level.

jul has similar multiple levels.

Arne

 

[Lew]

Logging is not intended only to be used for errors.

If we look at log4j log levels:

fatal
error
warn
info
debug
trace

then I agree that because we do not know if it is an error, then
we should not use the first 2 levels, but that leaves 4 levels
as potential candidates for level.

jul has similar multiple levels.

So does the Android 'Log' class.

 

[Jeff Higgins]

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.

A recent browsing session starting at

Computing - From Wikipedia, the free encyclopedia
<http://en.wikipedia.org/wiki/Computing>

led to

Laplante, Phillip (2007)
What Every Engineer Should Know about Software Engineering
<books.google.com/books?isbn=1420006746>

and

Software Engineering Body of Knowledge
From Wikipedia, the free encyclopedia
<http://en.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge>

and

Curricula Recommendations
Association for Computing Machinery
<http://www.acm.org/education/curricula-recommendations>

 

[Robert Klemme]

[...]
Well, you can forget the logging on *any* level of the application.
There is no really a difference between asking the author of this method
to do proper error handling or asking the author of some other code to
do it.

The caller has more context. When Integer.parseInt() is
unable to make sense of the input string, it has no way of knowing
whether the failure is fatal, unusual, or expected. Do you think
it should log all such failures in addition to throwing up?

No. That is exactly my point.

Cheers

robert

 

[Eric Sosman]

[...]
Well, you can forget the logging on *any* level of the application.
There is no really a difference between asking the author of this method
to do proper error handling or asking the author of some other code to
do it.

The caller has more context. When Integer.parseInt() is
unable to make sense of the input string, it has no way of knowing
whether the failure is fatal, unusual, or expected. Do you think
it should log all such failures in addition to throwing up?

No. That is exactly my point.

Okay, you've confused me. I maintain that the caller has more
context than the callee, and is therefore (often) in a better position
to make wider-scope decisions in handling errors. That, it seems to
me, is a distinct and notable difference in how the errors are handled.
Yet you say "there is really no difference" in handling an error Here
or There (or maybe even Elsewhere). I don't get it.

 

[Jeff Higgins]

Software Engineering Body of Knowledge
From Wikipedia, the free encyclopedia
<http://en.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge>

<http://martinfowler.com/bliki/Swebok.html>

 

[Jeff Higgins]

A recent browsing session starting at

led to

and

Fabio Paternò
End User Development: Survey of an Emerging Field for Empowering People
<http://www.hindawi.com/isrn/se/2013/532659/>