C style guide tips for a <80 char line

I 开发者_Python百科can't find many recommendations/style guides for C that mention how to split up lines in C so you have less then 80 characters per line.

About the only thing I can find is PEP 7, the style guide for the main Python implmentation (CPython).

Does a link exist to a comprehensive C style guide which includes recommendations for wrapping?

Or failing that, at least some good personal advive on the matter?

P.S.: What do you do with really_long_variable_names_that_go_on_forever (besides shortening)? Do you put them on the left edge or let it spill?

Here is Linus'original article about (linux) kernel coding style. The document probably evolved since, it is part of the source distribution.

You can have a look at the GNU Coding Standards which covers much more than coding style, but are pretty interesting nonetheless.

The 80 characters per line "rule" is obsolete.

http://richarddingwall.name/2008/05/31/is-the-80-character-line-limit-still-relevant/

http://en.wikipedia.org/wiki/Characters_per_line

http://news.ycombinator.com/item?id=180949

We don't use punched cards much anymore. We have huge displays with great resolutions that will only get larger as time goes on (obviously hand-helds, tablets, and netbooks are big part of modern computing, but I think most of us are coding on desktops and laptops, and even laptops have big displays these days).

Here are the rules that I feel we should consider:

One line of code does one thing.

One line of code is written as one line of code.

In other words, make each line as simple as possible and do not split a logical line into several physical lines. The first part of the rule helps to ensure reasonable brevity so that conforming to the second part is not burdensome.

Some people believe that certain languages encourage complex "one-liners." Perl is an example of a language that is considered by some to be a "write once, read never" language, but you know what? If you don't write obfuscated Perl, if instead you do one thing per line, Perl code can be just as manageable as anything else... ok, maybe not APL ;)

Besides complex one-liners, another drawback that I see with conforming to some artificial character limit is the shortening of identifiers to conform to the rule. Descriptive identifiers that are devoid of abbreviations and acronyms are often clearer than shortened alternatives. Clear identifiers move us that much closer to literate programming.

Perhaps the best "modern" argument that I've heard for keeping the 80, or some other value, character limit is "side-by-side" comparison of code. Side-by-side comparison is useful for comparing different versions of the same source file, as in source code version control system merge operations. Personally, I've noticed that if I abide by the rules I've suggested, the majority of my lines of code are sufficiently short to view them in their entirety when two source files (or even three, for three-way merges) are viewed side-by-side on a modern display. Sure, some of them overrun the viewport. In such cases, I just scroll a little bit if I need to see more. Also, modern comparison tools can easily tell you which lines are different, so you know which lines you should be looking at. If your tooling tells you that there's no reason to scroll, then there's no reason to scroll.

I think the old recommendation of 80 chars per line comes from a time when monitors were 80x25, nowadays 128 or more should be fine.