I've been reading books on phone since palm pilot and 160x160 screen.

I do not want to type / create on my phone though, certainly not code, or even sign up for stuff / submit / do applications on phone. Makes me a rarity though.

I've made edits to config files on the GitHub mobile app while on-call. Not something I like doing but I like having the option.

CWEB?

I don’t know how “common” it is, but (like I said in my comment) the only reason I read code on my phone is that I am often on a bus or a subway. The comment about assuming I only read on my phone is bizarre: you are putting words in my mouth for reasons I do not understand. When it comes to books I like paper, and I usually read long PDFs on a tablet.

It's worth noting that most of those studies are for body text. To make that more directly applicable we should exclude indentation, but the additional punctuation (especially commas, but unfortunately no parentheses) also affects it.

Shading lines can also improve readability (this is known; the rest of this comment is speculation). It's probably not enough to simply alternating between e.g. white and off-white background, unlike for tables. More likely an alternation between 3 or 4 subtly-different colors is best; maybe these can form a pattern across additional lines (e.g. 121312321). If the difference isn't subtle enough, editing will suffer whenever you break the line count, but for reference only the human eye is pretty good at aligning subtle things. Maybe even an outright paper-texture background image? (This is more often a gimmick, but it can be useful.)

    > especially with Python

What is special about Python in this case?

It's not, with a mouse I can scroll vertically with a Shift to scroll horizontally On a phone touch screen horizontal scrolling is also less ergonomic than vertical due to less range (and less ergonomic than vertical mouse), but I can't replace it

I mean, spelling the word “CAT” is hard if you don’t know how to do it, but as spelling goes, it’s pretty easy.

It’s true that some people are illiterate and never learned to spell. That doesn’t mean it’s hard, it just means they never learned how.

There's still reason to use line breaks, because many editors / viewers will wrap at the viewport width, not earlier, which is not always desirable. Different content "wants" to be different max widths.

For instance, I think prose is hard to read when you have to scan long horizontal distances from line to line.

However, code often has indentation, syntax, and chains (e.g. nested property access) that take up a lot of width before the actual information is presented, so width is more helpful.

Code is not only used in modern editors. Sometimes it is used in HTML, sometimes it is used in emailed patches, sometimes it is read as plaintext in some other context, it may be read or manipulated over a remote shell session in a terminal that has only rudimentary tools available during a production problem. There are many contexts where source code should be cleanly and clearly formatted and comprehensible without assistance from modern GUIs.

Delightful!

You know, there’s a reason cars and trains are the width that they are.

What I mean is that if I’m working on a file with some other people, and I write some 80-column code, they can easily view it in their nice wide panes, but I can’t easily view their wide code in my nice tiled square or vertical panes. I often have as many as 8 (or more!) tiles in a single fullscreen window.

In my experience, people who use wide monitors are more OK to longer lines. The opposite is true for tall/vertical monitor users. The next question: What is the chicken and what is the egg? Do people prefer narrower lines because they prefer tall monitors? Or vice versa?

All of my main external displays are 27". The diffs fit perfectly on them with the 80 character limit

I like to put a haikus in spots like this:

    // Empty by choice
    // Use the Prettier defaults
    // No customized rules

Taking the time to write a specific one gives added weight to the decision to use the defaults as anyone adding a rule has to remove the haiku.

Maybe even add a CI step that closes PRs if someone modifies formatter config files.

Yesterday I was running Prettier on an existing code base, and decided to go with 100. Even at 2-space indentation, 80 caused too many if-expressions to be split up. Google's JS styleguide also says 80. (I also have 450 character lines there, in a table of CSS classes for dark/light/selected/hover/disabled/focused modes. Leaving it long makes it much easier to confirm all modes set the right class.)

However, the benefit of automatic formatters is that if you really like 80 better, you can reformat before editing, and undo that before sharing your results.

Gotta admit a three-way side by side diff/merge is glorious.

Is there any editor with an intelligent soft-wrap? I.e. it doesn't just wrap at the end the window. Line breaks should be introduced so that the tree structure of the code (think AST) becomes obvious. That improves readability a lot compared to breaking lines at a fixed column.

> an autoformatter with the config checked into git is a nice way around this.

Yes. At my job we mainly use defaults of rustfmt in most repos. Some repos have rustfmt.toml in them. And the neat thing is that cargo picks up this automatically so there’s no per-repo config you have to do after cloning those repos in order to follow repo-specific formatting rules.

In CI we have a step that runs

  cargo fmt --all --check

And that exits with non-zero code if any formatting is different from what rustfmt wants it to be. Which in turn means that that pipeline stage gets marked as failed.

In order then to get your changes merged, you have to follow the same formatting rules that are already in use. Which in turn is as simple as having

  cargo fmt --all

run at some point before you commit. For example invoked by your editor, or from some kind of git hook or alias, or manually.

It’s nice and easy to set up, and it means that every Rust source file within each individual repo follow the same formatting as the other Rust source files in that same repo.

I don’t particularly care about what specific formatting rules each repo owner chose. (And the vast majority of our repos just use the defaults anyway.) All I care about when I’m working on code is that there is some kind of consistent formatting across the files in the project, and that formatting changes between commits from different people are kept to a minimum so that git log and git blame gives the info that you are interested in. So for me I am very happy that they do it this way at my job.

This approach comes with the benefit of automatically fixing those who simply don't realize their editor's settings disagreed with/didn't pick up on the conventions the project follows.

> I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions.

...it occurs to me, this feels like you're conforming to the tool instead of the other way around.

Is there a reason git blame doesn't have an "ignore whitespace" option? Is it harder than it seems?

Well I just want to fix the bug or write the feature and move on, but some want other things from their code.

I wouldn't say, I hate tabs. But I strongly prefer not using tabs in source code. Let me explain why. There are some languages and coding styles where it doesn't really matter. E.g. when you are always indenting by multiples of some indentation length. But there also languages and coding styles where you want to align stuff.

Consider this example:

    def someFunctionName(Int firstParameter, Boolean secondParameter, String thirdParameter)

Let's say, that line is too long. We could format it like this:

    def someFunctionName(Int firstParameter, Boolean secondParameter, 
        String thirdParameter)
    

Or we could format it like this:

    def someFunctionName(Int firstParameter, Boolean secondParameter, 
                         String thirdParameter)

Or event his

    def someFunctionName(Int firstParameter, 
                         Boolean secondParameter, 
                         String thirdParameter)

In the second two variant the indentation depends on the length of someFunctionName, so it is not necessarily a multiple of four or whatever your tab width is.

There are other similar situation when aligning in multiple columns, etc.

I simply find spaces easier to navigate. I don't always use vim-golf-winning movements, and when I am being lazy using hl or arrow keys, I expect to move a space at a time. Tabs violate that expectation.

It's a visceral rather than a rational thing (which I suppose is implied by the word "hate" :->). I also have trailing spaces and all tabs highlighted for similar reasons.

tabs are not great in Python because they can hide spaces, and that causes the code to break. in other code? i guess tabs are nicer because people can size them as they like on their devices.

Actually no I don’t want to be able to work like that on a laptop monitor. I’d rather optimize my full screen real estate. There in lies the conflict.

On my laptop, with a normal font (12-14pt) I can have a side bu side diff of 100 char wide text just fine.

120 is way too small. IMO 180 is a good limit. We're not on 800x600 screens anymore

I just bought an ultrawide, and I just checked to see how wide my lines are in my code editor. 350 characters.

When I'm coding for myself, I use all of that at times. I love that there are some things I no longer have to break onto multiple lines any longer.

Also, if you have a ton of nested loops etc, then you don't end up with that problem where you can only see the first few characters of the deepest lines.