How to follow the 80 character limit best practice while writing source code?

Question

So as you know there is a best practice saying

Limit a row of source code in 80 characters.

Here are 2 links:

Why is 80 characters the 'standard' limit for code width?

Is the 80 character limit still relevant in times of widescreen monitors?

And I am sure you can fine more if you search for this best practice.

But I find this extremely difficult, here is a sample example:

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> myReference

So you indent each class and each method and each statement.

And I am already at column 60 by the end of the last 'e' I have in 'myReference'.

I have 20 spaces left do actually call the constructor and assign the object to the reference I have.

I mean does this really look better:

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> myReference 
                = new HashMap<String, List<MyInterfaceHere>>();

What is the best practice here?

gnasher729 · Accepted Answer · 2016-03-16T13:25:44.950

The best practice should be "limit the length of a line so that you, all your colleagues, and all the tools that you are using are happy with it", plus some common sense. 80 characters seems to be very low and tends to reduce readability. I have once been totally tricked by a line like this:

/* Very long comment to the end of the line */ realCode ();

where the function call was not visible on the screen (neither was it visible on the screen of any colleague) with no indication.

I set my editor to display a 100 column margin, plus rewrapping the code on display, so everything is always visible while editing, and overly long lines tend to be manually split into two or sometimes more lines. Pray that your editor formats split statements nicely if it does auto formatting. Use a coding style that doesn't lead to deeply nested statements. (Some people create a nest of twenty if-statements followed by a tail of twenty else's which leads to 200 character deep indentation, and nobody can figure out which else belongs to which if).

In your particular case, Swift invented a way to avoid this: A "let" variable (which is about the same as "final" in other languages) must be assigned a value exactly once before it is used, but not necessarily in the declaration, so you could split your troublesome line into two independent statements.

PS. I have encountered lines, in real human-written code, that were over 400 characters. In other words, you'd have to scroll for ages to read the rest of the line, even on a 24 inch monitor. I was not amused :-(

score 4 · Answer 2 · answered Mar 16 '16 at 08:58

Yes, it does look better. That is why the "Don't use overlong lines!" maxim is so very strong.

As for best practice, I never, ever use these horribly long constructor expressions. I would always use

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> yReference = newMap();

for some suitably defined, statically imported value of newMap(). I consider it a grave defect in Java that it doesn't have built-in version.

score 4 · Answer 3 · answered Mar 16 '16 at 12:30

The goal isn't "keep lines to 80 characters". The goal is "make your code easy to read and comprehend". The artificial 80 character limit helps in readability, but it isn't a hard and fast rule unless your team decides it is.

You asked for the best practice, and the best practice is "focus on making the code as readable as possible". If that requires more than 80 characters, so be it.

score 4 · Answer 4 · answered Mar 16 '16 at 17:26

If you enforce line length/width of code, use a tool.

Resharper
Visual Assist
etc.

The developers decide what a reasonable length is (80, 120, 200, etc.), set that option in the tool.

After that, just write the code as you normally would without regards to how wide or long the line is. Once it is functional and finished, right click and choose Clean Up Code or similar option. The tool will format the code as you told it and break up long lines as indicated.

Mindless and easy and every source file will be formatted the same way.

score 2 · Answer 5 · answered Mar 16 '16 at 16:12

Don't be afraid of hitting the Return key. Most modern languages (including Java as in your example) are quite happy with statements that run across several lines.

Just put a little thought about where you break the lines, and you can get something that fits into an 80 column limit and still remains perfectly readable. The official Java coding conventions even specify preferred places to break lines.

Done right, a neatly broken up line is a lot more readable than one that disappears off the side of the screen.

score 1 · Answer 6 · edited Mar 16 '16 at 11:52

80 char limit may be a little too short these days, but it helps. I would agree with all those opinions that the code should be well formatted also. e.g. code

/* Very long comment to the end of the line */ realCode ();

may be within 80 chr but creates confusion as remarks and code options are on same single line.

To adhere to 80 chr limit or not to is individuals choice but if things are visible in single shot it will always give a comfortable view and feeling to programmers and other reviewers also.

score 0 · Answer 7 · answered Feb 12 '24 at 09:10

0

For .NET you can use an analyzer (NuGet package LeetKean.Analyzers.LineLength) that will add a warning (code LK0080) into your warnings list for every line longer than 80 chars.

answered Feb 12 '24 at 09:10

Dima

185

How to follow the 80 character limit best practice while writing source code?

7 Answers7