|
I can only fit 112 characters across a sheet of (letter size) paper, so that's what I limit my lines to in whatever editor I'm using.
It uses less than half the width of my screen, but at least that makes looking at diffs easier. :shrug:
|
|
|
|
|
Last time I printed from VS, the default seemed to be 120 characters per line, so I tend to stick with that.
Which also just so happens to fit quite nicely on a portrait-mode monitor (1920x1200) (1200x1920), plus one window docked vertically.
I have two such monitors side-by-side, with VS stretched across both, plus a third one (1920x1080) set up in the standard landscape mode for everything else.
|
|
|
|
|
dandy72 wrote: printed from VS
I don't do that; I use Word.
|
|
|
|
|
I can't remember the last time I printed anything! It isn't a consideration for anything I work on.
Hogan
|
|
|
|
|
I wasn't implying I print a lot of code.
Given the number of monitor sizes/resolutions, I decided I had to settle on *something*, so a printed sheet of paper seemed to make sense to me at a time. Having to scroll code horizontally, just because I happen to occasionally be on a smaller display, is a tremendous hassle (I know, first-world problem)...so even the crappiest display I might be stuck using will probably be wide enough to show at least one file without scrolling.
|
|
|
|
|
Fair enough. To tackle this issue, I use word-wrap. I essentially have the same environment on any monitor without having to perform any special formatting. I find the extra wrapping of code harder to read, but it sounds like I'm in the minority.
Hogan
|
|
|
|
|
snorkie wrote: To tackle this issue, I use word-wrap
<shudder>
snorkie wrote: it sounds like I'm in the minority
Probably. 
|
|
|
|
|
snorkie wrote: The more source code I look at, the shorter the lines seem to get
My wide monitor is wide enough that if I have two source files open side by side then I can see both. If the lines are short enough.
If I see source code where most lines require a wide monitor to see them (or to scroll) I would expect that the source code has a problem.
snorkie wrote: How do those developers deal with paperback books?
The random paperback book that I just picked up an counted one line had 54 characters. Rather certain that I have never read a paperback that had, say, 120 characters in a line. So not sure where your comment is going.
|
|
|
|
|
My comment about books is related to word-wrap. Most developers I work with can't seem to code with word-wrap turned on. It seems as simple as reading a book.
Since I read a fair amount, I have no issue coding with word wrap turned on, it just feels natural.
Hogan
|
|
|
|
|
snorkie wrote: Most developers I work with can't seem to code with word-wrap turned on. It seems as simple as reading a book.
Not sure I follow that.
Creating code is not the same as reading code.
In terms of literature wrapping (of any sort) is often based on word breaks and that works for text. But even in text that isn't true. For example if one has a bulleted section then letting the last bullet flow onto the next page, thus hanging out all by itself, is something that editors seldom do.
And code has more reasonable ways it which one can wrap than just breaks between tokens.
For example which of the following is more reasonable.
Something var = ({long expression)
+ (1+2)
Something var = ({long expression) + (1+2
)
|
|
|
|
|
I believe the point was if you can comprehend many characters per line in other media, why not in code. Paperback was a bad example but much written text has 100+ characters per line. Put another way, inability to read long code lines does not seem like the cause of short code lines.
|
|
|
|
|
MKJCP wrote: I believe the point was if you can comprehend many characters per line in other media, why not in code
As in the written word?
One difference is that a spelling error or a syntax error is unlikely to make a sentence unreadable. And certainly will not make the book self destruct.
That of course isn't true for code. That difference would seem like a substantial one.
MKJCP wrote: Paperback was a bad example but much written text has 100+ characters per line
Examples please.
Fiction books do not.
Non-fiction including text books do not.
Magazines do not.
|
|
|
|
|
You're right. It sure seemed like 100+. More like 90 based on the text books I just looked at.
|
|
|
|
|
Some monitors can be turned 90 degrees, so you can see a lot of lines, after changing the display mode 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
VS is too sidebar centric to play nice at even 1200px wide; and while I have rotated my 3" 2560x1600 screen to portrait before, it's too tall to be comfortably used that way.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
My "coding monitor" is rotated 90°. With short lines (my Vim configuration breaks them at 80 characters) I can still have 2 files in a vertical split and see their full horizontal contents.
It works very well if you also use a terminal (I use tmux) that allows splits, since you can have a small window at the bottom for builds, or htop, or both
|
|
|
|
|
I love wide monitors, but I don't use the width for code. Instead, I use half the width for code and the other half for let's say documentation. Or the dubugee. Or something else.
|
|
|
|
|
The human eye gets tired easily when being forced to scan across wide spans of text. That's why newspaper and magazine articles are split into columns.
|
|
|
|
|
Maybe I'm not human... 
Hogan
|
|
|
|
|
I actually have and like a wide monitor. I do break up a line when something in that line is more readable in a second line. I do this often in SQL like:
…
From tblMain m
Left join tblPoop p
On m.thing = p. thing.
That helps to tame the dyslexia for me.
|
|
|
|
|
Its an optimizing cash cow for those who get paid per line of code.
|
|
|
|
|
The resolution of monitors has dropped in recent years -- there was a huge backward reset when HD TVs came out and all the manufacturers retooled for producing flat panel TVs.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
There exists an optimum ratio between the linewidth and the interline spacing. I do not know its exact value but it is defined by the ease of following with the eyes the line and then switching to the next one. This is why the newspapers are printed in narrow columns instead of across the page.
|
|
|
|
|
Several people have mentioned the newspaper example. Its interesting, but code isn't a newspaper article. Rarely do I have several long lines in a row that require wrapping. Most code I see has tons of white space around lines of code for formatting/readability.
Hogan
|
|
|
|
|
At my company our coding standard strongly discourages formatting code that way. We frequently deal with XAML and Win32, so that means we sometimes have really long lines, but that's just how it goes.
It's really rare that anyone needs to actually see the entire line at once. Normally there are just a few items that actually matter, so we try to put those near the beginning of the line when possible (things like Name and Grid.Row/Column in XAML, for example). Generally, we find it much more useful to be able to get a sense of the structure of the code at a glance, and that gets broken when function calls are split into multiple lines. There are some rare cases where it makes sense to do that, of course, but that's stuff like building an xml file using stringstream.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
