Single Line Statements & Good Practices

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

This is really unusual coding style.

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

Answer 8

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.

Answer 9

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.

Answer 10

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.