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?

We make it 140. 80 might have been good in the days of smaller screens and smaller printers — tgkprog, Mar 16 '16 at 09:14
best practice [unless you're on End-Of-Life versions like 5/6](http://docs.oracle.com/javase/7/docs/technotes/guides/language/type-inference-generic-instance-creation.html) would likely be `final Map> myReference = new HashMap<>();` (80 chars with indentation like in your example) — gnat, Mar 16 '16 at 09:16
A meta-best-practice is not to blindly use best practices from twenty years ago. Back when a 17" CRT sported 1280x1024 resolution, lower character limits made sense, but not today. — TMN, Mar 16 '16 at 12:38
Note that one benefit of using narrow columns of text rather than sprawling across all available space in your display, is the ability to easily view multiple pieces of code side by side. `80 chars * 7 pixels/char = 560 pixels per file`. This allows two files (1120 px) to fit comfortably on a 1280 px wide screen, or three (1680 px) on a 1920 px screen, in both cases leaving some extra space for line numbers, scroll bars, sigils, and other UI elements. Or even the occasional slightly longer line. — 8bittree, Mar 16 '16 at 14:18
Code readability should be based on whatever makes the code easier to read, not on arbitrary restrictions like line length. If putting it on one line makes the code clearer but longer, that's what you should do. — Robert Harvey, Mar 16 '16 at 16:30
@8bittree I can view code side by side - on two monitors. Developing on a single monitor is like driving a car with only one wheel. — , Mar 16 '16 at 16:40
@Snowman And I assume that neither you, nor anybody you work with ever uses a notebook away from a desk, or ever wants to be able to look at something outside of your text editor alongside your multiple pieces of code. I usually use two monitors, with multiple pieces of code in one, and web browser in the other. — 8bittree, Mar 16 '16 at 16:45
Wow, old question :) I, for one, have it set to 120 chars. @8bittree those should be "life or death" scenarios when you are forced to work solely away from external monitors. Like, if I'm on vacation and some bug surfaced that wasn't caught and it breaks the app. Other than that, if I simply want to move on the couch for half an hour, away from the external monitors, I can survive for 30 minutes with 120 line length or I can enable word-wrap. Otherwise, you constantly need to have at least 2 windows in view, so line length would be the lesser evil, you need multiple monitors all the time. — MrCroft, Jan 04 '18 at 16:52

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 :-(

Seems like `/* Very long comment to the end of the line */ realCode ();` ought to already break some other style rules. — Robert Harvey, Mar 16 '16 at 16:27
`/* Very long comment to the end of the line */ realCode ();` is one reason why IDEs have code formatters that automatically put the comment and code on separate lines. — , Mar 16 '16 at 16:42
It came from the same source that wrote infamously "if (condition)\n\tgoto exit;\n\tgoto exit;". Just a few years earlier. — gnasher729, Mar 17 '16 at 09:08
I find that setting the max line length to 80 characters forces me to think in terms of functions and classes and OO, instead of writing a long line of text to do everything in a single shot. It makes me write programs that others can easily ready. Secondly, majority of the programemrs (In my experience) I have seen in SV work on their laptops, and dont have large screen displays available to them all the time. So writing in 80 character line limits helps everybody. Third, you can split your large monitor screen into multiple panes and view code simultaneously. — alpha_989, Jan 31 '18 at 18:10

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 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 4 · 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 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.

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

6 Answers6