Good line length?

[hunterboerner]

Should there be a line length limit? I have my editor set up to make text after 80 chars a vivid red. I think there also needs to be guidelines for wrapping function definitions:

# This is too long...
def handle_info(:run_build_script, state = %{config: %{repo: repo, script: scr, git_cmd: git_cmd}}) do
...
end

[bbense]

I think long function definitions might be a code smell, but if you have to have them I'd much rather have them on one single line. I think line length limits are generally a mistake because they cause more readablity problems than they solve.

Having short lines as a goal is good, doing stupid coding tricks just to get a line under X chars is not good.

[hunterboerner]

@bbense so don't do complex pattern matching in the function definition?

[whatyouhide]

Elixir is prone to long lines I think because of what @hunterboerner mentioned: big function heads. This is an example from marco_polo:

defp parse_live_query_content(<<op_type, token :: int, record_type, version :: int, cluster_id :: short, position :: long, rest :: binary>>, schema) do

I can't really make it shorter without losing either clarity or performance.

Another example is some stdlib functions (Erlang in this case but you get the point) that can make a line long without making it complex at all. This is a real-world line from marco_polo as well:

days = date_to_gregorian_days(date.year, date.month, date.day) - date_to_gregorian_days(1970, 1, 1)

All of this just to say that yes, probably "enforcing" a line length limit in the style guide may be too much?

[bbense]

No, don't limit yourself to 80 chars if you need to do complex pattern matching in function definitions.

If that's what you really need to do, then do it and don't worry about some silly line length guideline.

If you think before you break the rule, then breaking the rule is fine. That's what I mean by code smell, not that you shouldn't do it, but that you should think if that's really the right thing before doing it.

To be honest, there is much in this style guide that I think borrows too much from rules of thumb in Ruby. Elixir is still too young to know what the rules of thumb will be that lead to maintainable code.

[asaaki]

Btw. when it comes to numbers I would say that 80 is definitely not contemporary anymore.

Besides this I would say you should find your own limit. And this number will be perhaps a very personal one. Ask yourself: How much information (here characters per line) I am capable to grasp?

Furthermore this might be also influenced by your editor/IDE setup you use; how much information regularly fits on your screen. Unless you develop on really low resolution tiny screens and/or side-by-side split windows I'm pretty sure most of the time you have a lot of whitespace to the right.

Considering both statements it's hard to tell where you should wrap your code. It might be 80, but could also easily be more or even less.

Therefore I think a style guide can't really help here.

And as the Ruby style guide was mentioned here: in general I think a lot of their recommendations are pretty good, but some like "80 characters per line" are always things I override in every project.

Update My personal rule of thumb is: If I have to scroll horizontally too often then it seems to be time to think about how much stuff I've put into the lines.

[whatyouhide]

Guess the consensus is that we can close this one?

[Gazler]

Maybe instead of explicit line length - we should advise on line break techniques?

For a long def some of the functions in the core split on the when:

  def put_new_lazy(keywords, key, fun)
      when is_list(keywords) and is_atom(key) and is_function(fun, 0) do
    case :lists.keyfind(key, 1, keywords) do
      {^key, _} -> keywords
      false -> [{key, fun.()}|keywords]
    end
  end

https://github.com/elixir-lang/elixir/blob/b6888c408cc129262b3e4d9cc5e7b78d1ee4a4ab/lib/elixir/lib/keyword.ex#L397

[doomspork]

+1 for not setting a specific line length. Most styleguides seem to suggest 80 yet I've never participated in a project that enforced it. Why have styles in a guide that you intend to ignore?

I personally try to keep my lines under 120 but in reality I just keep things clean and do whatever works best.

[hunterboerner]

Maybe instead of explicit line length - we should advise on line break techniques?

This would be nice.

[eksperimental]

Should we mention that no line length is defined by this guide.
Also maybe it will be good to include (maybe int his section).
also maybe mention that if people want to choose one, they can use
http://editorconfig.org/

I will propose to include this in the tools section, as it is appropriate to set up the space configuration and line break

[divmgl]

This is something that I've struggled with as well and 80 characters simply won't do anymore. I've upped to 100 and as @bbense mentioned, it's all about comfort.

That being said, +1 on the line break techniques. Many times I have gone to a new-line and asked myself, "is this correct? Should I be moving this to a new line?"

[eksperimental]

👍 on the including a line breaking technique

[dandv]

I try to keep the line length under 130 characters - the width of GitHub's file viewer, so code reviewers don't need to scroll horizontally.

[sgeos]

The erlang guidelines I found state 100 columns per file.

Erlang Coding Standards & Guidelines
https://github.com/inaka/erlang_guidelines

100 column per line

Stick to 100 chars per line, maximum.

Examples: col_width

Reasoning: Excessively long lines are a pain to deal with: you either have to scroll horizontally while editing, or live with ugly line wrapping at arbitrary points. The 100 character limit also keeps lines short enough that you can comfortably work with two source files side by side on a typical laptop screen, or three on a 1080p display.

[whatyouhide]

This is something that the new Elixir code formatter will take care of, so I think this issue can be closed.

[christopheradams]

@whatyouhide I noticed that the code formatter defaults to a line length of 98 characters. Do you have any insight on why this exact length was chosen? My naive guess is that if you comment out a line of code it will still not be longer than 100 characters. :)

[whatyouhide]

@christopheradams just a good looking line length, I don't remember any particular reason to make it 98. It's customizable anyways :)

[crabonature]

@whatyouhide

Great that it is customizable :)

The most beautiful lines of code are less than 70 characters. In computer science as I remember it was always less than 80 characters.

Just longer lines are harder to focus on them read them and you need more time to process them by brain.
The same rules from ages is in literature (50-70 characters per line), poetry (no more than 10 words per line) and other fine arts.

For example:
https://eric.ed.gov/?id=EJ749012
http://www.sciencedirect.com/science/article/pii/S1071581901904586

In computer science if there is a need to write line more than 80 characters it's probably good place for refactoring code or sometimes refactoring language.

[christopheradams]

I don't remember any particular reason to make it 98.

I just asked @josevalim this question. He chose 98 so that it wouldn't take sides for any default preference. If it were 100 then someone would argue for 80. This way no one is happy. 😁

[asaaki]

Microbikeshedding: why not 97 or 99 instead?