Inserting Multiple Lines from Console

[subhabangalore]

Dear Group,

I was trying to get input of different nature of string, int etc.

To insert multiple lines I can do sort of standard coding like,

public class BRReadLines {
public static void main(String args[]) throws IOException
{
// Create a BufferedReader using System.in
BufferedReader br = new BufferedReader(new
InputStreamReader(System.in));
String str;
System.out.println("Enter lines of text.");
System.out.println("Enter 'end' to quit.");
do {
str = br.readLine();
System.out.println(str);
} while(!str.equals("end"));
}
}

I may assign string and int also. But I was looking to assign different variable names like,
String str;
int In;
.....
and read from console.

Initially I did
str=br.readLine()
and
In=br.read()

but did not help much,
then I am trying like,

BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
BufferedReader br1 = new BufferedReader(new InputStreamReader(System.in));

str=br.readLine();
In=br1.read();

It is generally going okay but when the output is being generated I am getting arbitrary output.

If anyone can kindly suggest how may I improve it?

Regards,
Subhabrata.

 

[Stefan Ram]

If anyone can kindly suggest how may I improve it?

public class Main
{
public void quit(){ java.lang.System.exit( 0 ); }

public void main() throws java.lang.Throwable
{ final javax.script.ScriptEngine scriptEngine
= new javax.script.ScriptEngineManager().getEngineByName( "JavaScript" );
scriptEngine.put( "main", this );
final java.lang.StringBuilder text = new java.lang.StringBuilder();
scriptEngine.put( "text", text );
scriptEngine.eval( "print('');" ); // loads engine for faster reaction
java.lang.System.out.printf
( "*** Texteditor 2000, V1.0 ***%n%n %d Bytes Free%n%n Enter%n%ntext." +
"append('example');%n%n or other StringBuilder calls in JavaScript " +
"syntax to edit,%n%n or enter%n%nmain.quit();%n%n to quit.%n%n",
java.lang.Runtime.getRuntime().freeMemory() );
while( true )try
{ java.lang.System.out.printf( "%n> ", text );
java.lang.System.out.println
( scriptEngine.eval( System.console().readLine() ));
java.lang.System.out.printf( "%s%n", text ); }
catch( final java.lang.Throwable throwable )
{ java.lang.System.err.println( throwable ); }}

public static void main( final java.lang.String[] args )
throws java.lang.Throwable { new Main().main(); }}

 

[Joerg Meier]

public void quit(){ java.lang.System.exit( 0 ); }

Aside from the horrible, horrible JavaScript advice that I honestly pray
you posted as a joke, why are you qualifying java.lang things ?

Liebe Gruesse,
Joerg

 

[markspace]

I was trying to get input of different nature of string, int etc.

It is generally going okay but when the output is being generated I
am getting arbitrary output.

I think first your main problem is trying to define the problem. You
need to define what "nature" you want to read in what circumstances.
Nobody just reads lines and turns them into strings or ints on a whim.

If you need some definition because your just doing this on your own,
consider writing a simple parser for algebraic input. Parsers are
common in computer science, so they're good to know about, look it up.

The next step is to define some test cases. Here's some lines you
should be able to read in and parser correctly. Note that I'm assuming
you'll do this "algebraically" and that * and / get evaluated before +
and -.

1 + 1
-10
1243 + 678 * 5
1 / 3
45 - 34 + 12 - 90 + 78 * 3 / 2

 

[Daniel Pitts]

Aside from the horrible, horrible JavaScript advice that I honestly pray
you posted as a joke, why are you qualifying java.lang things ?

The fully qualifying of classes, as well as the strange indentation, is
typical of Stefan. I usually ignore his code snippets, but do try to
comprehend his non-code.

 

[Lew]

Yes, that is the really strange thing there.

He's pretty aggressive about refusing to comply with community standards.

The fully qualifying of classes, as well as the strange indentation, is
typical of Stefan. I usually ignore his code snippets, but do try to
comprehend his non-code.

In this case it's a bizarre answer.

The suggestion to use Scanner or a string tokenizer was better.

 

[znôrt]

In this case it's a bizarre answer.

i found it amusing, and quite brilliant.

The suggestion to use Scanner or a string tokenizer was better.

instead of pointing to some basic building blocks with which to build a
rudimentary parser, he presented a working solution using a complete
parser already available to java. i would definitely hire this guy! xD

and his code style isn't that bad. anyway if your eyes start to bleed
just paste into eclipse and hit ctrl-shift-f!

 

[Lew]

In this case it's a bizarre answer.

i [sic] found it amusing, and quite brilliant.

This is a Java newsgroup, and the OP clearly was trying to learn Java.

The suggestion to use Scanner or a string tokenizer was better.

instead of pointing to some basic building blocks with which to build a
rudimentary parser, he presented a working solution using a complete
parser already available to java [sic]. i [sic] would definitely hire this guy! xD

Not appropriate for the question, though.

and his code style isn't that bad. anyway if your eyes start to bleed
just paste into eclipse [sic] and hit ctrl-shift-f!

You don't work in a professional programming environment with source control and
code reviews, do you?

Formatting changes introduce more to review and get wrong. They are frownedupon.

Everywhere I've worked has insisted on a house style before checkin is permitted.

Also, I program on a Mac a lot of the time, so Ctrl-Shift-F doesn't work, and when at
home I usually use NetBeans, which has a different key chord.

Not everyone uses Eclipse or NetBeans, either.

Stefan is notable for his attitude about conventional formatting and simpletype names.

 

[znôrt]

Not appropriate for the question, though.

he did show some functionality that java has out of the box, and how to
use it in a smart and effective way.

You don't work in a professional programming environment with source
control and code reviews, do you?

i do. hell i do! and standups and retrospectives and breakfasts and
coding dojos and checkstyles and freaking sonar pedantic warnings are my
everyday's cross to bear. and let's not forget common criteria! that's
why i can appreciate some fresh air sometimes. and some bizarre-ness for
a change, why not

Formatting changes introduce more to review and get wrong. They are
frowned upon.

indeed. i didn't suggest raping any house rules either.

Everywhere I've worked has insisted on a house style before checkin is
permitted.

i have to assume you wouldn't work in a shop run by stefan xDDD

This is a Java newsgroup, and the OP clearly was trying to learn Java.

you have a point there. and it's nice that someone pointed out that
stefan's contribution is unconventional, but then there is still some
value to it i wouldn't dismiss just because it is unconventional or is
something ... well, that would be most probably frowned upon in a
conventional sw engineering dept.

 

[Arved Sandstrom]

In this case it's a bizarre answer.

i [sic] found it amusing, and quite brilliant.

This is a Java newsgroup, and the OP clearly was trying to learn Java.

The suggestion to use Scanner or a string tokenizer was better.

instead of pointing to some basic building blocks with which to build a
rudimentary parser, he presented a working solution using a complete
parser already available to java [sic]. i [sic] would definitely hire this guy! xD

Not appropriate for the question, though.

and his code style isn't that bad. anyway if your eyes start to bleed
just paste into eclipse [sic] and hit ctrl-shift-f!

You don't work in a professional programming environment with source control and
code reviews, do you?

Formatting changes introduce more to review and get wrong. They are frowned upon.

The problem there sounds more like unclear ownership of source code. The
move away from formal checkout-checkin in source control systems
(although oddly enough not in many other systems, like CMS or ECM)
doesn't mean that there shouldn't be _informal_ checkout-checkin, i.e.
at any given time only certain individuals should have "ownership" of a
file, optimally one person per file per branch.

If this informal policy is observed, formatting changes accompany real
changes, and sometimes the formatting changes *are* the real changes.
Basically this kind of "known ownership" goes a long way to eliminate
dabbling, including casual formatting tweaks.

Everywhere I've worked has insisted on a house style before checkin is permitted.

I've worked in places that had a "house style" and enforced it, places
that said they had one but didn't enforce it, and on projects that
didn't have one at all. I've found that the need for a house style
diminishes if coders know not to dabble and nitpick, they know only to
do a format if it's an intentional _refactoring_ of sorts to improve
maintainability, and the individual styles of people are good (IOW, good
coders).

To the latter point, I have no problem working with another programmer's
style if it's clear and makes sense. If I have been called upon to make
minor mods, I adopt the style.

Also, I program on a Mac a lot of the time, so Ctrl-Shift-F doesn't work, and when at
home I usually use NetBeans, which has a different key chord.

Not everyone uses Eclipse or NetBeans, either.

Stefan is notable for his attitude about conventional formatting and simple type names.

AHS

 

[znôrt]

The problem there sounds more like unclear ownership

if there is a problem at all with formatting you can use a centralized
mandatory style configuration shared by all developers, and automatic
formatting on save. voilà.

of course this only applies to "professional programming environment
with source control and code reviews" (which is the current context),
where you have control over the tools.

once you do that you never bother again on formatting or styling issues,
not for a second, and bytheway realize that poor code quality has
absolutely nothing to do with formatting or style at all.

 

[Eric Sosman]

if there is a problem at all with formatting you can use a centralized
mandatory style configuration shared by all developers, and automatic
formatting on save. voilà.

of course this only applies to "professional programming environment
with source control and code reviews" (which is the current context),
where you have control over the tools.

once you do that you never bother again on formatting or styling issues,
not for a second, and bytheway realize that poor code quality has
absolutely nothing to do with formatting or style at all.

Why do so many programming languages -- including Java --
allow the programmer the freedom to use arbitrary amounts of
white space between tokens? Perhaps it's to give petty tyrants
something to obsess about: As long as they're busy insisting on
their own rigidly-defined white space allocation rules, they'll
perhaps lack the energy to do something more troublesome.

Meanwhile, mechanically allocated white space is occasionally
a bad thing. Case in point: I recently wrote a bit of code to
solve a small system of linear equations using Cramer's Rule. You
may recall that this involves calculating matrix determinants --
that's one reason it's not especially good for large equation sets,
but this one was only three-by-four. So I wrote myself a method
of nine arguments, and called it like this:

double d = determ(sumXX, sumXY, sumX,
sumXY, sumYY, sumY,
sumX, sumY, n );

double a = determ(sumXC, sumXY, sumX,
sumYC, sumYY, sumY,
sumC, sumY, n ) / d;

double b = determ(sumXX, sumXC, sumX,
sumXY, sumYC, sumY,
sumX, sumC, n ) / d;

double c = determ(sumXX, sumXY, sumXC,
sumXY, sumYY, sumYC,
sumX, sumY, sumC ) / d;

See the nice, neat three-by-three matrices? See how the column
of right-hand sides (the ...C terms) marches neatly across the
tableau? See Cramer's Rule exactly as your high-school algebra
textbook pictured it?

Along came the ever-helpful mechanical formatter:

double d = determ(sumXX, sumXY, sumX,
sumXY, sumYY, sumY,
sumX, sumY, N);

double a = determ(sumXC, sumXY, sumX,
sumYC, sumYY, sumY,
sumC, sumY, N) / d;

double b = determ(sumXX, sumXC, sumX,
sumXY, sumYC, sumY,
sumX, sumC, N) / d;

double c = determ(sumXX, sumXY, sumXC,
sumXY, sumYY, sumYC,
sumX, sumY, sumC) / d;

See the matrices? They're still there, if you sort of tilt your
head to the side and squint a little; it may help if you're slightly
astigmatic. See the right-hand sides in their systematic little
dance? Not I, not with all the head-tilting my vertebrae can manage.
Somebody's insistence on his own notions of formatting (as embodied
in the mechanical formatter) transformed my code from crystal-clear
to opaque and ugly.

Perhaps I should just be thankful it left the line breaks
in place. It doesn't always, you know! About a month ago I used
this well-known pattern:

Quotation quo = new Quotation.Builder()
.setDate(elt.getAttribute(DATE))
.setPrice(elt.getAttribute(PRICE))
.setSize(elt.getAttribute(SIZE))
.setSource(elt.getAttribute(SOURCE))
.build();

.... which the friendly formatter turned into:

Quotation quo = new
Quotation.Builder().setDate(elt.getAttribute(DATE)).setPrice(elt.getAttribute(PRICE)).setSize(elt.getAttribute(SIZE)).setSource(elt.getAttribute(SOURCE)).build();

.... after which the check-in system dinged me for line length.

 

[Gene Wirchenko]

On Wed, 10 Apr 2013 14:43:39 -0400, Eric Sosman

[snip]

See the matrices? They're still there, if you sort of tilt your
head to the side and squint a little; it may help if you're slightly
astigmatic. See the right-hand sides in their systematic little
dance? Not I, not with all the head-tilting my vertebrae can manage.
Somebody's insistence on his own notions of formatting (as embodied
in the mechanical formatter) transformed my code from crystal-clear
to opaque and ugly.

Of course, it can go the other way around, too. Sometimes,
formatters do help clean up code. One reason that I have avoided
using code formatters though is because sometimes, aesthetics is
important. Your code is an example of this. Another would be a
function/method call with some parameters that are important. How
would you split (typed all on one line):


retval=functionname(importantparm1,importantparm2,option1,option2,option3,option4,option5);

I would probably use
retval=functionname(importantparm1,importantparm2,
option1,option2,option3,option4,option5);
or
retval=functionname(

importantparm1,importantparm2,option1,option2,option3,option4,option5);
It is extremely unlikely that I would use
retval=functionname(importantparm1,importantparm2,option1,option2,
option3,option4,option5);
but how do I specify what the aesthetics are?

Perhaps I should just be thankful it left the line breaks
in place. It doesn't always, you know! About a month ago I used
this well-known pattern:

Quotation quo = new Quotation.Builder()
.setDate(elt.getAttribute(DATE))
.setPrice(elt.getAttribute(PRICE))
.setSize(elt.getAttribute(SIZE))
.setSource(elt.getAttribute(SOURCE))
.build();

... which the friendly formatter turned into:

Quotation quo = new
Quotation.Builder().setDate(elt.getAttribute(DATE)).setPrice(elt.getAttribute(PRICE)).setSize(elt.getAttribute(SIZE)).setSource(elt.getAttribute(SOURCE)).build();

... after which the check-in system dinged me for line length.

Are you coming? We got you.
Are you going? We got you.

Sincerely,

Gene Wirchenko

 

[Eric Sosman]

On Wed, 10 Apr 2013 14:43:39 -0400, Eric Sosman

[snip]

See the matrices? They're still there, if you sort of tilt your
head to the side and squint a little; it may help if you're slightly
astigmatic. See the right-hand sides in their systematic little
dance? Not I, not with all the head-tilting my vertebrae can manage.
Somebody's insistence on his own notions of formatting (as embodied
in the mechanical formatter) transformed my code from crystal-clear
to opaque and ugly.

Of course, it can go the other way around, too. Sometimes,
formatters do help clean up code. [...]

That, I think, should be their main purpose and use case.
Refactor a bunch of deeply-nested code into a method of its
own, and a mechanical reformatter is a great convenience in
re-adjusting the nesting levels. Throw a loop or an if() around
something, ditto. And, of course, every so often you encounter
some wretched piece of code where twenty different programmers
have used thirty different styles -- the mechanical cleaner-
upper can be as helpful as forty maids with forty mops.

But I truly think casual use of reformatters is a bad idea.
Some folks require them at check-in ("Unless thy code pass
unchanged through the reformatter, Lo! I say unto thee that it
shall not enter the Kingdom of Checkin"), and some apply them
routinely at check-out ("Nobody should care what the code in the
repository looks like, because everyone reformats it to his own
style when working on it anyhow"). Both practices, it seems to
me, are capable of destroying or at least obscuring information.[*]

[*] For an extreme example of code that would be damaged by
mechanical reformatters, note that Whitespace code embedded in
Java code (perhaps for steganographic purposes) would be quite
unlikely to survive Java-oriented reformatting.
http://en.wikipedia.org/wiki/Whitespace_(programming_language)

 

[Stefan Ram]

double d = determ(sumXX, sumXY, sumX,
sumXY, sumYY, sumY,
sumX, sumY, n );
Along came the ever-helpful mechanical formatter:
double d = determ(sumXX, sumXY, sumX,
sumXY, sumYY, sumY,
sumX, sumY, N);

That is a rather half-hearted reformatter! A real
reformatter should be able to strip the information
about the line breaks, too, giving something like

double d = determ(sumXX, sumXY, sumX, sumXY, sumYY, sumY, sumX,
sumY, N);

. Especially for this purpose I used a special reformatter,
called »Jacobe«, that one could call with a maximum line
width of »1« to obtain an output with one token per line!
Next, I passed it through the Eclipse formatter to get what
many people declared to prefer. It was thus stripped of all
formatting information of the original source to the maximum
extend possible.

Sadly, Jacobe was not updated for Java 1.7, so I had to
refrain from using it.

A thorough reformatter should parse the source into an AST
and then build a new source from that AST. (The line breaks
are not part of the AST.)