261–270 of 330 posts
Jesus, what a bullshit. It's not about screen size, it's about reading experience. If you think that longer lines making something easier to read - try to read non-trivial book with 100 characters width.
Earlier quoted context omitted.
Then pipe through perl -pe 's/\\\n//g' Before grepping
Turning the entire file into a single line really doesn't seem like a solution. Now foo(1, bar, false) print("Hello, world") flag = true shows up in your grep output, and not in a particularly helpful rendering.
foo(1, \
bar, \
false)
print("Hello, world")
flag = \
true
foo(1, bar, false)
print("Hello, world")
flag = true
foo(1, bar, false)Earlier quoted context omitted.
100% the reason I'm a tab guy. If I'm glancing at some code on my phone, I can have it set to two space tabs to maximize the amount that fits on screen. If I'm on my desktop they're four spaces because my screen is huge and more visibly apparent indentation is valuable. Same editor, same data. If it's a shared codebase and someone else likes 8 space tabs, 6 space, or whatever they want (13 space? no kinkshaming here.…
Yep. I have yet to hear a coherent argument against tabs. It’s such a tiresome squabble.
The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. Take it from the world of books: This study may be helpful: > This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 c…
Yeah, when you do typesetting you quickly learn that ~10 words per line is a sweet spot for readability.
The large number of symbols in many languages that are clearly not words in the usual sense might make the comparison a bit tricky, or wouldn't it ?
Optimal reading width is like 40-90 characters, and if I end up with an excessively long line, often times, I’ll try to rewrite a bit, not just line-break my first thought, but use it as a creative spur to write better. Personally, I like 80 character lines. If I need more than 80 characters in a line, I treat it as a code smell.
I don't personally feel that the indentation most programming languages employ have any effect at all on my reading, unless possibly it's too narrow as code is partially read as a graphical construct. Hence limiting the length of the entire line to an equal width seems unnecessarily restrictive.
The only things that changed are developers and their developer setups. We got better, wider monitors and we got used to using longer variable and function names.
80 characters is an arbitrary constraints that requires me as a developer to think how I am structuring my code. It also makes it easier for me to read the code as 60 characters is about perfect column width for readability.
Earlier quoted context omitted.
How can you make a linter for this?
If the author thinks it's okay, and the reviewer thinks it's okay, a robot that can't actually understand code doesn't need a vote.
Earlier quoted context omitted.
Buy a bigger monitor. Or get glasses. I'm 38, rocking a 43" 4k monitor. There's so much room. Scale things up or down to your comfort level. It's a pleasure if you use an editor like atom.
> I'm 38, rocking a 43" 4k monitor. There's so much room. There's no more room on a 43" 3840 x 2160 monitor than there is on a 32" 3840 x 2160...
Earlier quoted context omitted.
Buy a bigger monitor. Or get glasses. I'm 38, rocking a 43" 4k monitor. There's so much room. Scale things up or down to your comfort level. It's a pleasure if you use an editor like atom.
Is it a TV? If so does it work well for small text and are there any negatives vs a monitor?
The refresh rate might be slower, so of you get annoyed by a 30Hz refresh rate, you'll want to make sure the TV does 60Hz.
Nowadays I'm guessing anything but the cheapest models can do it for any given resolution, but some diligence is probably in order as TV specs are not as uniform and reliable as monitor specs.