Number of characters recommended for a statement

Question

Hi,

I have been using Qt 4.5 and so do C++.

I have been told that it's a standard practice to maintain the length of each statement in the application to 80 characters. Even in Qt creator we can make a right border visible so that we can know whether we are crossing the 80 characters limit.

But my question is, Is it really a standard being followed? Because in my application, I use indenting and all, so it's quite common that I cross the boundary. Other cases include, there might be a error statement which will be a bit explanatory one and which is in an inner block of code, so it too will cross the boundary. Usually my variable names look bit lengthier so as to make the names meaningful. When I call the functions of the variable names, again I will cross. Function names will not be in fewer characters either.

I agree a horizontal scroll bar shows up and it's quite annoying to move back and forth. So, for function calls including multiple arguments, when the boundary is reached I will make the forth coming arguments in the new line.

But besides that, for a single statement (for e.g a very long error message which is in double quotes " " or like longfun1()->longfun2()->...) if I use an \ and split into multiple lines, the readability becomes very poor.

So is it a good practice to have those statement length restrictions? If this restriction in statement has to be followed?

I don't think it depends on a specific language anyway. I added C++ and Qt tags since if it might. Any pointers regarding this are welcome.

Answer 1

80 chars width is quite common I believe. It is the recommendation in the Java coding conventions from Sun too.

I always stick to it. Perhaps not in first writing, but always before I check something in.

Answer 2

Nobody likes having to scroll sideways, so you should break your statement into pieces, at or before the 80-character mark. That doesn't mean the statement can't be more than 80 characters long - sometimes it will have to be.

For example, this is taken from one of my own source files that I happened to have open:

if ( cmdline.HasFlag( FLAG_QLIST ) && cmdline.HasFlag( FLAG_SMARTQ )) {
    CSVTHROW( "You cannot specify both " << FLAG_QLIST
                << " and " << FLAG_SMARTQ << " flags together");
} 

where the error message is split in two to avoid going over the 80-character margin.

And see also this question.

Answer 3

Yes, I think this is good practice. 80 might be a little bit overkill, with today's screens, I think 120 is a good choice.

But if your code is so long to break the limit, your code has a problem. Things like longfun1()->longfun2()-> are not easily debuggable, you cannot breakpoint in the 'middle' of the chain call.

As you specified, for function calls, breaking in multiple lines will improve your code. Moreover, you will have a better metric with your LOCs and can more easily break up function.

I guess what I want to say is : yes, stick to it.

Answer 4

80 character width is the java code convention just because older terminals had often a size of 80x25(24). Since code should be readable even on old systems, they suggest to use that width. In some java certifications you could even get punished if you dont (SCJD).

On the other hand, common displays feature a width of about one bazillion characters, so increasing the line length to about the size of a4/letter could increase readability.

As long as your stick to one width youre good to go.

Answer 5

With modern screens, I find about 120 characters a good value. Also, usually my variable/method names are descriptive and thus might be somewhat long.

If you have are running out of screen width, it usually is a sign that:

• The code is too deeply nested, so break it into several methods.
• You are chaining too many method calls behind each other, so break them up.

The second case can also happen with long conditions, i.e.

if (something && somethingElse && moreThings && anotherThingWhichMightBeTrue)
{
    // Do something
}

I find it greatly improves readability if you break these down into logical groups, such as

bool someCondition = something && somethingElse;
bool anotherCondition = moreThings && anotherThingWhichMightBeTrue;
if (someCondition && anotherCondition)
{
    // Do something
}

Answer 6

You might also want to consider the trouble of comparing files side by side. Even on modern screens you could run into problems with long lines there.