Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Inserting Multiple Lines from Console

Reply
Thread Tools

Inserting Multiple Lines from Console

 
 
zn├┤rt
Guest
Posts: n/a
 
      04-10-2013
Arved Sandstrom <(E-Mail Removed)> writes:

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

>
> 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.
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      04-10-2013
On 4/10/2013 1:45 PM, zn├┤rt wrote:
> Arved Sandstrom <(E-Mail Removed)> writes:
>
>>> Formatting changes introduce more to review and get wrong. They are
>>> frowned upon.

>>
>> 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.


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.ge tAttribute(SIZE)).setSource(elt.getAttribute(SOURC E)).build();

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

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Gene Wirchenko
Guest
Posts: n/a
 
      04-11-2013
On Wed, 10 Apr 2013 14:43:39 -0400, Eric Sosman
<(E-Mail Removed)> wrote:

[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,opti on3,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.g etAttribute(SIZE)).setSource(elt.getAttribute(SOUR CE)).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
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      04-11-2013
On 4/11/2013 2:11 PM, Gene Wirchenko wrote:
> On Wed, 10 Apr 2013 14:43:39 -0400, Eric Sosman
> <(E-Mail Removed)> wrote:
>
> [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/Whitesp...ng_language%29

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      04-11-2013
Eric Sosman <(E-Mail Removed)> writes:
> 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.)

 
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
Preserve blank lines when add multiple lines of text to a cell Cah Sableng Javascript 0 04-23-2007 04:46 AM
inserting lines PG Perl Misc 13 10-03-2006 12:20 AM
Inserting lines into text files, or howto "fix" vCards having no n: entry analogquack@gmail.com Perl Misc 7 06-07-2006 08:59 PM
Inserting Lines into HTML Header Roy Schestowitz HTML 10 06-13-2005 08:17 AM
multiple changes on multiple lines Dave Perl Misc 1 04-02-2005 05:06 PM



Advertisments