Thread: Opinion on line length

Prefer 80. Not set in stone.

[edit]For one system I forced myself to reduce it by about 10, which annoyed me, because it made looking at the generated assembly much more tolerable.

I just let it go on for as long as it needs. Shorter lines get their comment at the end of the line. Longer lines get their comments placed above the line.

Of course, if it's really really ridiculous, then I'll hit enter somewhere in the middle of the line...sometimes. But then again, if you're bordering on 150 charactesr per line, you can probably break it up into smaller chunks, and not just rely on "Enter" to make everything look good.

(In my current project, my longest line is 182 characters. One of the exceptions to the "smaller chunks" suggestion).

Heh, it's just a really long function definition:

Code:

void cWindow::Init(char BackgroundPath[50], HINSTANCE *hInstance, unsigned int ClassStyles,
unsigned long WindowStyles, unsigned int Width, unsigned int Height, HBRUSH DefaultBrush)

The longest "in-function" code I have is 167:

Code:

if(FAILED(D3DXCreateFont(D3DDevice, 22, 0, FW_NORMAL, 1, false, DEFAULT_CHARSET,
OUT_DEFAULT_PRECIS, ANTIALIASED_QUALITY, DEFAULT_PITCH|FF_DONTCARE, "Arial", &Font)))

(I split them both up here so as not to have ginormous scrolling action going on.

It's really just my personal preference. Once I write the code, I know it works, and if there's little chance of me going back to change it, then I really don't need to be looking at it. And if I do have to, well, I'll just scroll a little. The long lines usually only happen when I'm filling in parameters for a function, or writing the definition for a function.

Code like this (120 characters):

Code:

float Weight = (TERRAIN_HEIGHT / NUM_TEXTURES - abs(Height - ((I + 1.0f) * dT - 1.0f)) / TERRAIN_HEIGHT / NUM_TEXTURES;

Got split up into:

Code:

float dT = TERRAIN_HEIGHT / NUM_TEXTURES;

float dY = Height - ((I + 1.0f) * dT - 1.0f);
					
if(dY < 0.0f)
	dY = dY * -1;

float Weight = (dT - dY) / dT;

Like I said, for function definitions, they'll stay. For longer pieces of code, I'll usually break it down like that. It helps a lot in being able to debug, especially with long math equations or similarly complex code.

C coding style standards differ between projects, groups, and individuals. Most of them are based on the notion that the code will be viewed in a standard 80 column terminal or printed on 80 column paper. I've tended to use 76 or 78 as my maximum line length. Some 80 column displays and printers automatically perform a newline when a character is displayed in column 80, and then the newline at the end of the 80 character line displays as an empty (blank) line. Other terminals wrap (perform the newline operation) when an attempt is made to display a character in the 81st position. Real DEC VT terminals have the latter behavior, many others have the former.

Why 80 columns? That's historical. IBM 029 punch cards had 80 columns, thus could contain 80 characters per card. Many video terminals provided 80 columns in order to match the line length of a punch card.

I've only worked in one place where the C coding standard allowed a maximum of 72 columns per source line in order to allow for the last 8 columns to be used for a punched card sequence number, but that was common in Fortran coding style standards.

Thus endeth the history lesson.