Should editors update 80 columns guide to something wider? | Hacker News Reader

Should editors update 80 columns guide to something wider?

7 pointsmilani18 comments

With wide screens, 80 characters/columns guide seems unreasonable. Don't you think so?

Any particular fixed width is inherently stupid in some way. 78? 80? 132? 255? All crap. Still, having some fixed width is inherently useful. Encourages readability. Permits stodgy old guys like me to print and annotate code for reviews/debugging. And it encourages making people think when going from column N to column N+1 that maybe there's a better way to restructure the logic to make it more expressive.

That said, 80's been with us for awhile. Your question is like asking if it would make sense to increase automobile widths. We inherited those. And, from a more recent generation, we inherited 80 columns. Stick with it.

Telling people to use 80 columns because "we inherited it" is just cargo-culting. Intelligent people will rebel against that.

Instead, tell people the actual reasons why we use 80 columns. It is because your eyes have to physically move as you read a line of text. Forcing them to move too far causes excessive eyestrain. Additionally, when lines are excessively long, you lose your place in the document by the time you get to the end of the line.

These are the same reasons why newspapers have multiple columns, even though it would be easy for them to put everything into a single giant column. Shorter columns are more readable.

In a way, the question is akin to asking why we still have minimum font sizes even on "retina" displays. You can buy a monitor that can display teeny teeny fonts, but you can't buy eyeballs or a brain that can make sense of them. Similarly, you can easily have giant lines of code on any monitor from the last 20 years. But good luck reading them.

There are some additional issues which are specific to computer code. One is that extremely long lines often come from excessive nesting, an antipattern.

I wish that a mainstream language would come about that uses a proper encoded AST as "source code", thus making the point moot, as people could display format as they wish. unfortunately, this has not come about thus far.

However, it's still (almost) a moot point to me. I almost never code in 80 characters (generally closer to 130ish. Fits two windows nicely side-by-side on my screen.), but if something requires it I have my IDE set up to reformat it when I am done.

The T in AST means that any straightforward textual representation is going to come out isomorphic to Lisp. But if you try something non-straightforward, then programmers will have to do the mapping between text and AST in their heads, which defeats the purpose.

Thus what you're asking for reduces to either (a) a mainstream Lisp, or (b) a language whose programs naturally translate into something other than a tree. (a) is a can of rather boring worms, but (b) seems like it could use more attention. The only thing I know of in that space (maybe) are stack languages.

(b) Dataflow programming?

And the entire point of storing the "source" on-disk as an AST is to not have the programmer directly edit the file. Use an editor set up to handle it.

Sort of like JSON. Yes, you can read and edit it manually, but it's primarily meant for something else.

In most dataflow languages (e.g. Lucid) the source text is still parsed into a tree; it's the order of execution at runtime that is unusual. That is, dataflow languages are tree-based lexically, but not temporally. A counterexample would be interesting. Is there one?

Edit: it feels like if one found a textual notation that matched the dataflow graph in the way that s-exprs match ASTs, that could lead to a Lisp of dataflow languages. I have no idea what that would look like or whether it would be tractable for building real-world systems, but it would be an interesting experiment.

I strongly disagree that Lisp-style s-exprs are the solution to this problem. They preclude future-proofing language tools. If feature X is currently described as a n-tuple, and I want to enhance it, I must now either create a new tag (which breaks tools) or increase its arity (which necessarily centralizes language development). A solution to this would be to represent nodes as key-value sets. There is precedent for this: XML and CSS both work this way.

I agree that key-value sets (hashmaps, associative arrays, whatever one calls them) are even more convenient for programming than lists are. A pet idea is to create a Lisp that takes the hashmap as its native representation. (My cofounder is working on it!) However, it would be beyond tedious to have to assign every code element an explicit key, so in practice one wants to generalize s-exprs into what one might call t-exprs ("table expressions") in a way analogous to how Lua lets tables have a special integer-indexed array portion. Semantically, everything is a table (hashmap); notationally, most forms look just like s-exprs. But now they can be augmented with arbitrary key-value pairs.

I don't feel future-proofing is as big a deal as you do, but I do think that certain programs and (especially) tools would be easier to write in a hashmap-based Lisp, where the programmer and/or tool could attach whatever metadata they wanted to any section of code. There are potentially some order-of-magnitude wins there, I think. Production Lisps usually tack on various kinds of magic metadata anyway (e.g. symbol-plists, docstrings, Common Lisp's declare, Clojure's metadata). The above idea would unify all of those by promoting the underlying generic construct to first-class status.

I stick to 132 character lines and display two files next to each other at the same time. If I stuck to 80 character lines, I could have three files on screen at the same time.

There's a limit to how wide code can be while remaining readable, even though it can be wider than prose: I struggle to read prose that word wraps at 132 columns, and I expect I'd struggle to read code that used 200 columns.

I do. Others don't care. Others act like they would rather die than agree to any other style. (tell them you're indenting with 5 space long tabs and watch them twitch)

It's really about the personal preferences and about what the project advertises as the agreed coding style. Ideally I'd like to see editors and the whole toolchain that accept and work on some encoded ast rather than text finally, so that everyone can see the text as they prefer. Until then we do need to agree on some standards in our own environment.

If you wanted an answer for stats: I program on full screen terminal, so between 120 and unlimited is my preference.

Some IDEs like XCode don't allow you to customize this setting.

I would say that wide screens should typically be for multiple windows, not a single wide window. Get out of the habit of reflexively maximising everything that we picked up while using 4:3 CRTs.

I've got two guides - one at 80 and one at 120. Code can sometimes get out to 120, but I always keep comments to 80. It makes the comments easier to read, but it also allows me to use more screen space for code if necessary.

It's not about the screen or the computer; it's about the primate sitting in front of it. Long lines are unreadable. That's why newspapers have multiple columns.

Sure. But sometimes the strict limit forces you to do things that are worse than just leaving the long line, simply to comply with some automated coding style enforcement. For example sometimes you have to break up strings into separate parts and wrap the last argument following them to it's own line for readability... Even if the same arguments pattern if used all over the project (so one line would be more recognisable / readable). So you get 3 lines that are worse (for example) to grep than one line just because it would have 85 characters otherwise.

Long lines are unreadable, enforced short lines are unnatural, common idea of the best judgement doesn't exist. :(

Newspapers can deal with this by squeezing words / letters together, or allowing more space in some lines to make the text align better. Code using monospace font can't do the same.

Using grep with strings that span multiple lines is not a big deal. Use the -A and -B flags, as well as --with-filename.

Widely agreed-on code standards do exist. Usually they are either 80 or 100 characters per line.

This is not always true:

    log.msg("error with " +
            "some description")
    
    grep "error with some description" ...

Yes, there are standards for coding. They are usually 80 or 100 characters. And each one has a different way of handling the wrapping cases, splitting strings, wrapping values (parens, line join with \, concatenation, etc.)

You can use something like this:

  grep --with-filename -A 3 error $FILES | grep -C 3 description

If that's not elegant enough for you, there are even tools like pcregrep that can do multiline matches. Don't uglify the code because of easily solved tool problems.

Reply on news.ycombinator.com