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?

  • 5
    This might be a good question for codereview.stackexchange.com
    – Matt McHugh
    Aug 26, 2011 at 20:43
  • 2
    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, 2011 at 20:48
  • 2
    If you're asking a coding style question, it'd help if you'd specify the language.
    – Caleb
    Aug 27, 2011 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? Aug 27, 2011 at 8:36
  • 1
    And also, I'm used to automated formatting (Java), where code gets a uniform look anyway.
    – Kwebble
    Aug 27, 2011 at 20:43

10 Answers 10


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.

  • 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, 2011 at 8:55

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

  • 3
    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, 2011 at 23:51
  • 1
    @anon Good point about merge tools as well; one statement per line means fewer merge conflicts to clean up.
    – Hugo
    Sep 18, 2011 at 20:34

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

  • 3
    The same concept applies to debugging, where once again the granularity is typically a line number. Aug 27, 2011 at 15:25
  • 3
    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). Aug 30, 2011 at 10:56

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.


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.

  • 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, 2011 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. Aug 31, 2011 at 8:45

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!";

This is really unusual coding style.

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


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.


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.


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


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


  • 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.
  • Some of the "cons" may at times be pros. For example, suppose a piece of code has eight consecutive operations of the form if (x > maxX) {x=maxX; peggedAny = true;}. If each such operation will fit easily on a single line, I would rather have eight lines like that than dozens of lines which split out the statements. If such comparisons were used in enough places, four statements of the form peggedAny |= pegValueMinMax(ref x, minX, maxX); might be better, but someone reading that would have to read pegValueMinMax to see what it does.
    – supercat
    Jul 15, 2014 at 17:54
  • Further, if a small piece of a line changes, a "diff" will regard that as a change to the whole line. If the line should behave functionally as a unit, that would be a good thing. Otherwise, if a semantic operation is split among multiple lines, changes to some lines might affect the operation in ways which would not be apparent.
    – supercat
    Jul 15, 2014 at 17:58
  • It's not easier to read something horizontally - we read code from top to bottom. It's common for developers to split the code window vertically when working on multiple files, which introduces an issue was developers are then forced to scroll horizontally in order to read a line of code. Nov 17, 2022 at 12:30

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