Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have recently acquired a habit which I know many of you may frown upon, but which, in the end, helps me keeping an eye on global code structure rather than on the structure of a single, (sometimes) repetitive method: grouping a number of statements in a single line, like this:

textBox1.Text = "Something!"; textBox2.Text = "Another thing!"; textBox3.Text = "Yet another thing!";

as opposed to

textBox1.Text = "Something!";
textBox2.Text = "Another thing!";
textBox3.Text = "Yet another thing!";

I use to do that for repetitive tasks to maintain overall code "beauty" and to help me tracking program structure easily, but I admit it may not be a good practice. I actually use it a lot, so I would like to know what are your thoughts on this. Also, do you think that anyone which would ever have to maintain my code have problems with this approach?

share|improve this question

migrated from stackoverflow.com Aug 27 '11 at 1:40

This question came from our site for professional and enthusiast programmers.

5  
This might be a good question for codereview.stackexchange.com –  Matt McHugh Aug 26 '11 at 20:43
    
I will have problem if I were to maintain. The first thing that I would do is do a CTRL+F for ";" and put a line break. But that is just me :-). I do like one line only if I have a reasson to, example initialize enabled properties of a few text boxes with a default value of false: textBox1.Enabled = textBox2.Enabled = false; –  Arun Aug 26 '11 at 20:48
2  
If you're asking a coding style question, it'd help if you'd specify the language. –  Caleb Aug 27 '11 at 3:52
3  
While it may not arise in the example given, how are you going to put a breakpoint on the second or third or ... statement if you are putting them all on one line? –  Marjan Venema Aug 27 '11 at 8:36
1  
And also, I'm used to automated formatting (Java), where code gets a uniform look anyway. –  Kwebble Aug 27 '11 at 20:43
show 2 more comments

10 Answers

Syntactically, there is really nothing wrong with it. It really depends on the coding style of your team.

As most of the code I have seen (including the code that is inside the standard c++ headers) is done this way, I would go with your first method.

textBox1.Text = "Something!";
textBox2.Text = "Another thing!";
textBox3.Text = "Yet another thing!";
share|improve this answer
add comment

One-statement-per-line is a widely used coding style. As a result, most developers who look at your code in future will probably wince when they see multiple statements per line. When you're used to seeing something one way, it can be disorienting to see it another way.

For this reason I advise against it, except in rare circumstances.

share|improve this answer
add comment

This is really unusual coding style.

I would recommend you to use empty lines to delimit logical parts of code instead.

share|improve this answer
add comment

Going too far off to the right can create just as many problems as multiple lines.

I've had to deal with some sql statements with dozens of fields. Normally, I'd put one per line, but on a few occassions, I've consolidated 3 or 4 to a row. This seems like a good idea during development when you're having to scroll up and down several times.

I regret returning to this code. Having extra rows just doesn't seem to create that much of a problem so I usually clean it up.

share|improve this answer
add comment

I really think readability would suffer greatly both for you and certainly anyone else reading the code. It all makes sense when you write it the first time because it's actively in your mind. It's different when you're scanning code to see what variables and functions are where...you're destroying your own ability to scan your own code. That's a huge no-no, and beyond bad if anyone else ever has to read your code.

Also, think about how you read code. It's always top down, scrolling down. Your method doesn't mesh with this, and even introduces one of the ugliest possible issues in code reading; scrolling horizontally. Never underestimate how hard that can make reading code. You never scroll horizontally, you never make people scroll horizontally, in almost any context it's extremely unnatural.

Also, if your issue is repetitive code entry...don't forget Ctrl-C. From your example code it might be more efficient to type that all out manually, but if you have to copy a bunch of lines a bunch of times it seems like it would be just as efficient to copy line one plus a new line, paste it x times and make the changes, less likely to make a typo too.

Oh, and typos! Harming the readability of your code like that can make it a nightmare to find which of the 50 variable declarations you set wrong. Most compilers give errors at row AND column numbers now, but finding an error at a row is MUCH easier than finding a column.

share|improve this answer
2  
a) Reading/Scanning code - Most people when scaning code read the first few characters of the line then move on unless it's "interesting", then they read a couple more. Compiler Errors : Most of the time I interpret the compiler error as "Problem with line <x>". only if I can;t work it out instantly (rare), so I actually read the error. –  mattnz Aug 27 '11 at 8:55
add comment

I last did this 25 years ago using interpreted languages on small micros running with low clock speeds, where every space or carriage return eliminated gave a performance increase.

I wince now at the thought of it (though it was done for a good reason).

Unfortunately such code is difficult to read, and thus difficult to maintain.

share|improve this answer
1  
So you write it properly, then strip whitespace and any other prep for your "machine copy". Just like minifying javascript nowadays. –  CaffGeek Aug 30 '11 at 16:28
1  
Yeah - I wrote a program to reprocess source code like that too - back in 1986. Another thing I hope to never need to do again. –  quickly_now Aug 31 '11 at 8:45
add comment

One statement per line also makes it easier to see what has changed in a side-by-side diff.

share|improve this answer
2  
This is probably the biggest reason, if someone has to merge that code, almost all merge tools are going to make it easier to isolate and move lines rather than substrings of rows. –  anon Aug 31 '11 at 23:51
    
@anon Good point about merge tools as well; one statement per line means fewer merge conflicts to clean up. –  Hugo Sep 18 '11 at 20:34
add comment

While the example doesn't show this, there's another problem with grouping multiple statements on one line. What if one of the five statements you have on a single line throws an exception?

Your stack trace will say "EBlah at line N"... and now you have no idea which of those five statements threw the exception.

(The same thing happens with an excessively long statement of any kind.)

share|improve this answer
2  
The same concept applies to debugging, where once again the granularity is typically a line number. –  David Hammen Aug 27 '11 at 15:25
2  
Oh my yes, this can be a problem. A “favorite” is when you get a null pointer loose in something like foo.bar[grill.boo].flip.flap[flop].mickey(minnie).marshmallow (Java/C# syntax). Sorting through that sort of mess is always better with extra lines (and temporary variables… and a 2D6 Brick Of Clue for the original developer). –  Donal Fellows Aug 30 '11 at 10:56
add comment

Also, do you think that anyone which would ever have to maintain my code have problems with this approach?

After putting his hands on his head for a minute, he will use its favorite IDE Regex functionalities to automatically separate all that unreadable code into one statement per line.

Just a quick look at the example you showed is enough to understand how much more readable is the second approach.

It's much easier to follow the vertical page flow, without having your eyes to move horizontally forever.

Look at your example: you immediately know the code is all about the Text property of different textBox objects, and they contain string as values. Pretty straightforward.

share|improve this answer
add comment

I wouldn't personally use such a style. To summarize

Pros

  • fewer lines of code to scroll through
  • can be used to semantically group code to express: "a lot of assignment stuff". BUT you can always refactor such a block into a function if it bothers you too much.

Cons

  • difficult to read, it's generally easier to read code horizontally (skimming, no eye movement, ...)
  • diff easily becomes a nightmare, including merging
  • more difficult to change (copy&paste, commenting out, ...)
  • debugging can be a problem in many IDEs as they work on lines instead of individual expressions.
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.