• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Which is easier to read:

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
In my opinion, putting parameters (or anything of multiples for that matter) on their own separate line is just stupid. It takes up way too much screen space and doesn't make the code any easier to read.

What I am used to (and I develop in a very process driven industry with strict style guidelines) is that you should never exceed 80 characters per line, so if you want to print of your code for a review (or whatever) it all fits on one line and doesn't wrap.

Anything else is fair game.

Slap him and tell him to stop being so anal. Its not HIS code.
 
1) The person you are working with is unprofessional. No one should ever edit another persons code without permission! There is something called sense of accomplishment and if someone is doign this, it is totally inappropriate, especially if it is a superior of yours like a software lead.

2) The new format is the worst way of doing things. That siad, to many parameters on one line also sucks.

The only real answer is that you need to make it clean and human readable while not wasting space. I usually wrap long lines following the 80 column rule. I'd possibly do this.
ProductItem productItem = new ProductItem(pd.RGB, pd.Name,
index, pd.ProductGroup,
"User Defined");

You can not see it, but each line would line up with the opening parenthesis from the first line.

Any way you do it, you should try to be consistent through a project and there should be style guidelines. REMEMBER THOUGH, GUIDELINES ARE NOT REQUIREMENTS.

It is my opinion that code should be as compact vertically as is possible. Within reason of course. That way, it is easier to read and understand the flow.
 
Originally posted by: 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.
Click to expand...

Get a wider monitor 😉

techfuzz
Click to expand...

I think the 80 column rule is antiquated. We do not print code out much anymore and monitors can support more columns. Form palying around though, you can't do much more than 80. 100 is pretty good but if you were to do 100+ things start getting messy.
 
Also, many people do not do it, but on average every 5 lines of code should have a comment. You think your code will be perfect for you and never need maintenance but I can tell you from experience that if you think this you are naive.
 
in this case, there is only 5 items in parameter.

but if its something over 10 items, option #2 would be better.

also, option #2 should be like this

ProductItem productItem = new ProductItem
(
pd.RGB
, pd.Name
, index
, pd.ProductGroup
, "User Defined"
);
 
I like to code using option #2 a lot myself for a variety of reasons. Mainly its easy to check for syntax errors in your code, and generally it gives a sense of code hierarchy that option 1 does not. IMO its like coding in sentences vs coding in bullet points. Your method may code fine, but when you want to review the i/o in a function call its going to a little bit harder.

As others have mentioned, when you get functions w/ many inputs a one-liner makes it that much harder to align input with function variables.
 
Originally posted by: Common Courtesy
#2 ONLY IF you are going to self document each parameter
Click to expand...

They should be documented at the method declaration. There are situations where the call should be separated onto two lines but one line for each parameter is just weird and wasteful.
 
Originally posted by: IHateMyJob2004
Originally posted by: 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.
Click to expand...

Get a wider monitor 😉

techfuzz
Click to expand...

I think the 80 column rule is antiquated. We do not print code out much anymore and monitors can support more columns. Form palying around though, you can't do much more than 80. 100 is pretty good but if you were to do 100+ things start getting messy.
Click to expand...

I also rarely, if ever, print code. The 80 column rule for me comes from various projects' style guides: If the code I'm working on has a style guide, I follow it to the best of my sanity.

Otherwise, I format it such that I can read it conveniently on a framebuffer console. 🙂 I prefer a windowing environment, but I try not to assume one.
 
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.

Maybe he works under the Peter Principle.
Click to expand...

Yeah, it works for Wall of SQL... hate trying to pick through a 4,000 character SQL statement to see which value is somewhere.
 
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.

Maybe he works under the Peter Principle.
Click to expand...

^^
 
These debates are always stupid. Get a code formatter and run it to your prefered style when you work on it, he can do he same when he does.
 
I prefer the first one. I hope the other guy did other more productive things besides wasting his time reformatting your code.
 
I use both styles, it depends on what parms are being passed. For example, in web development, some jquery ui or extJS calls would be wrapping around my screen if I did not break then down into individual lines.
 
I use both styles. Depending on what I'm doing, I usually opt for Style 1, but if I have a funky function I go for Style 2. That keeps me keen to all that's going on.
 
Originally posted by: techfuzz
1

2 is just painful to look at

techfuzz
Click to expand...

I'm just learning how to program but I like to keep my code all neat and on one line(option 1) because it is much easier to read and fix my many, many mistakes.
 
I use whatever style is easier to understand and read.

Sometimes this requires me to break things down in mutiple lines (sql queries especially)

If I have trouble reading and understanding code quickly, there is a problem right there.

My time should be spend coding. Understanding lines of code should be easy if done in a clean and efficient manner
 
I consider horizontal whitespace to be valuable. You want logical sections of code to fit on one screen since it makes it a lot easier to understand code as a whole. Goofy seperation of calls definitely impedes this...
 
#2 is perfectly acceptable if doing #1 would require scrolling to read any part of that line of code. Sometimes this is necessary even with 5 or fewer variables because you are in line of code that is nested levels deep within code constructs (i.e. namespace->class->method->loop->boolean->etc) and therefore have a high number of indents on the line of code. I hate having to scroll left and right when reading or working with code.
 
Originally posted by: degibson
Originally posted by: IHateMyJob2004
Originally posted by: 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.
Click to expand...

Get a wider monitor 😉

techfuzz
Click to expand...

I think the 80 column rule is antiquated. We do not print code out much anymore and monitors can support more columns. Form palying around though, you can't do much more than 80. 100 is pretty good but if you were to do 100+ things start getting messy.
Click to expand...

I also rarely, if ever, print code. The 80 column rule for me comes from various projects' style guides: If the code I'm working on has a style guide, I follow it to the best of my sanity.

Otherwise, I format it such that I can read it conveniently on a framebuffer console. 🙂 I prefer a windowing environment, but I try not to assume one.
Click to expand...

The only problem with style guides is that "experienced" software people tend to write them. The 80 column guide is antiquated but still around for one reason. People with more experience (aka: used to doing things the way they used to) write the guides and put in the 80 column rule for the sake of putting in the 80 column rule.
 
Frankly the latter is one of the reasons I hate Delphi ... seems like most Delphi programmers do that. One friggin line please so I don't look at half lines of code trying to figure out what it does.
 
Our style guide states that if you do any wrapping at all then you should put each parameter on it's own line. Whether to wrap or not is left to the discretion of the individual.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top