
Should editors update 80 columns guide to something wider? - milani
With wide screens, 80 characters&#x2F;columns guide seems unreasonable. Don&#x27;t you think so?
======
RhysU
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.

~~~
cmccabe
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.

------
TheLoneWolfling
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.

~~~
gruseom
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.

~~~
colanderman
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.

~~~
gruseom
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.

------
mooism2
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.

------
viraptor
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.

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

------
frou_dh
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.

------
debacle
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.

------
cmccabe
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.

~~~
viraptor
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.

~~~
cmccabe
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.

~~~
viraptor
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.)

~~~
cmccabe
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.

