Which is easier to read:

[Train]

Another coder at work has been going through my app and changing this:

ProductItem productItem = new ProductItem(pd.RGB, pd.Name, index, pd.ProductGroup, "User Defined");

With this:

ProductItem productItem
= new ProductItem
(pd.RGB
, pd.Name
, index
, pd.ProductGroup
, "User Defined"
);

And its driving me nuts. Am I the only one who thinks breaking every method or constructor call down to one param per line is a waste?

 

[Schadenfroh]

I do not like the FuseTalk style of the latter.

 

[Modelworks]

A waste of what ?
Its not like blank lines or a chr(13) is going to eat up space.

 

[Train]

Originally posted by: Modelworks
A waste of what ?
Its not like blank lines or a chr(13) is going to eat up space.

a waste of time and screen space

 

[presidentender]

One param per line is a waste of screen real estate. Get a style guide and stick to it. If there is no style guide, then it's your code, and he should keep to your conventions when modifying it.

 

[nakedfrog]

Option 1

 

[Drakkon]

ive used one param per line when setting up fairly lengthy calls (i.e. when it wraps to 1 or more lines) but not for ALL calls.

 

[Cogman]

sometimes I do something like

Blah = new Longblahwithlotsofstuff(thing1 thing, thing2 thing
thing3 thing, thing4 thing);

Where thing3 is lined up with the parenthesis.

 

[techfuzz]

1

2 is just painful to look at

techfuzz

 

[mundane]

Originally posted by: Drakkon
ive used one param per line when setting up fairly lengthy calls (i.e. when it wraps to 1 or more lines) but not for ALL calls.

 

[Train]

Originally posted by: mundane

Originally posted by: Drakkon
ive used one param per line when setting up fairly lengthy calls (i.e. when it wraps to 1 or more lines) but not for ALL calls.

he does it for ALL, even if its one or two params.

 

[Adul]

he needs to get a life, is there some sort of coding standards doc

 

[drebo]

Option 1 is much easier to read.

I've used similar to Option 2, but only ever in very long SQL queries.

For general programming, Option 2 is a waste of time and screen space.

Maybe he works under the Peter Principle.

 

[Markbnj]

I only break method signatures to preserve width restrictions, then I simply wrap and indent by the normal amount.

 

[jjones]

Originally posted by: drebo
Option 1 is much easier to read.

I've used similar to Option 2, but only ever in very long SQL queries.

For general programming, Option 2 is a waste of time and screen space.

Agreed.

 

[tfinch2]

If I do something like option two it looks like:

ProductItem productItem = new ProductItem(pd.RGB,
pd.Name,
index,
pd.ProductGroup,
"User Defined");

Where the first char of each arg is aligned. This is for functions with 7 or more args. I don't waste my time with 5...

 

[xtknight]

1 any day of the week. 2 is a big ugly mess to me. Only separate giant calls.

 

[nace186]

unless the line go off the screen, then I'll break it to 2 line.

 

[RocksteadyDotNet]

I always use first option, even if it goes of screen.

 

[degibson]

I like to maintain 80-character (or depending on the project style restraints, sometimes 60 or 70) width. I wrap parameters to maintain that width... I don't believe in using one style in all cases. It also varies by language.
However, my default is no wrapping.

 

[techfuzz]

Originally posted by: degibson
I like to maintain 80-character (or depending on the project style restraints, sometimes 60 or 70) width. I wrap parameters to maintain that width... I don't believe in using one style in all cases. It also varies by language.
However, my default is no wrapping.

Get a wider monitor

techfuzz

 

[EagleKeeper]

#2 ONLY IF you are going to self document each parameter

 

[Glitchny]

Originally posted by: xtknight
1 any day of the week. 2 is a big ugly mess to me. Only separate giant calls.

 

[KB]

Get this guy something else to do. Maybe he can work on the database or the Reports.

 

[clamum]

Option 2 looks weird. Not sure I've seen another coder do that. One line fo sho.