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?

  • 4
    We make it 140. 80 might have been good in the days of smaller screens and smaller printers – tgkprog Mar 16 '16 at 9:14
  • 6
    best practice unless you're on End-Of-Life versions like 5/6 would likely be final Map<String, List<MyInterfaceHere>> myReference = new HashMap<>(); (80 chars with indentation like in your example) – gnat Mar 16 '16 at 9:16
  • 2
    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
  • 2
    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
  • 2
    @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. – user22815 Mar 16 '16 at 16:40
up vote 12 down vote accepted

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

  • 6
    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
  • 2
    /* 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. – user22815 Mar 16 '16 at 16:42
  • 2
    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 9: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 at 18:10

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.

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.

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.

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.

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.

protected by gnat Mar 17 '16 at 15:22

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.