C for tooltips for <80 char

Question

I can not find many recommendations / style guides for C that mention how to split lines in C so that you have less than 80 characters per line.

About the only thing I can find, PEP 7 , is a style guide for basic Python implantation ( CPython ).

Is there a link for a comprehensive style C guide that includes packaging recommendations?

Or, if this is not the case, at least some good personal recommendations on this?

PS: What are you doing with real_long_variable_names_that_go_on_forever (other than shortening)? Do you put them on the left edge or skip?

Answer 1

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

Answer 2

You can familiarize yourself with the GNU coding standards , which covers much more than the coding style, but is nonetheless interesting.

Answer 3

80 characters in the rule string are out of date.

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 no longer use punch cards . We have huge displays with excellent resolutions, which will only increase over time (obviously, handheld computers, tablets and netbooks are a large part of modern computing, but I think that most of us code on desktop computers and laptops, and even laptops have big displays these days).

Here are the rules that I think 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 the logical line into several physical lines. The first part of the rule helps ensure reasonable brevity, so the second part is not burdensome.

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

Besides complex single-line lines, another drawback that I see in accordance with some restrictions of an artificial nature is the reduction of identifiers to comply with the rule. Descriptive identifiers without abbreviations and acronyms are often clearer than abbreviated alternatives. Clear identifiers bring us closer to competent programming .

Perhaps the best “modern” argument I've heard to preserve an 80 character or other meaning is a side-by-side code comparison. Side-by-side comparison is useful for comparing different versions of the same source file, for example, in a merge operation of source code version control systems . Personally, I noticed that if I adhere to the rules that I suggested, most of my lines of code are short enough to view them completely when two source files (or even three for three-way merges) are examined side by side on a modern display. Of course, some of them overwhelm the viewport. In such cases, I just scroll a little if I need to see more. In addition, modern comparison tools can easily tell you which lines are different from each other, so you know which lines you should look at. If your tool tells you that there is no reason to scroll, then there is no reason to scroll.

Answer 4

I think the old recommendation of 80 characters per line comes from the time when monitors were 80x25, now 128 or more should be ok.