|
Visual Studio on 1280x1024 == 125 columns (with Solution Explorer/Class View/VA X View taking some of the space).
It seems to be a pretty fair standard to me. 80 is too small nowadays and 200 is too much for normal people.
I rarely ever print code.
|
|
|
|
|
DrFrankenstein90 wrote: It seems to be a pretty fair standard to me. 80 is too small nowadays and 200 is too much for normal people.
I agree with this point. Although I'll use 120 instead of 125 to be compatible with other systems.
|
|
|
|
|
Why wasn't this a choice in the survey? We rarely print our code anymore and screen size in itself isn't really an issue.
RZ
|
|
|
|
|
Readability, to me, is the main issue. It is rare that I print out code any more. By breaking up long lines and indenting the continuation lines, the code becomes easier to read and understand: that means, in my book, easier to debug.
|
|
|
|
|
Agreed; even if I didn't print, I still wouldn't use the longest lines my (current) monitor can display.
|
|
|
|
|
I consider that anything beyond 125 columns is bad practice. Even if your screen looks like a movie theater screen.
A programmer should always consider that some other guy will read the code, sooner or later.
Jm
www.menendezpoo.com
|
|
|
|
|
|
lol
Jm
www.menendezpoo.com
|
|
|
|
|
And at one point some person will need to print a piece of it to try to understand your logic.
John
|
|
|
|
|
I'd have to get up and walk around a couple of cubicles to get to the printer, so I hardly ever print source code. Width of the screen minus any toolscreens in the IDE is my line length limit.
|
|
|
|
|
I used to limit the length to 80 charactes so I could print the code. I haven't printed a single line of code in several years, and now I am a little more relaxed about that rule. I still try to keep most lines under 90, but 2 or 3 extra chars won't do any harm.
|
|
|
|
|
Usually my lines are rather short, I tend to split up lines so it becomes more readable, like this:
int someValue = dbConnection.CreateSomeStatement().Execute().Value
becomes
Statement stmt = dbConnection.CreateSomeStatement();
Whatever foo = stmt.Execute();
int someValue = foo.Value;
Of course that's not always the case, but you get the idea.
Same for some if-blocks:
if (foo != null && foo.HasSomeFlag() && foo.HasSomeOtherFlag && foo.FooFooFoo())
becomes
if (
foo != null &&
foo.HasSomeFlag() &&
foo.HasSomeOtherFlag &&
foo.FooFooFoo()
)
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
I would likely make the first one:
int someValue = dbConnection.CreateSomeStatement().
Execute().Value ;
(leaving the dot at the end rather of one line rather than putting it at the start of the next.)
And the second one:
if
(
foo != null
&&
foo.HasSomeFlag()
&&
foo.HasSomeOtherFlag
&&
foo.FooFooFoo()
)
so the &&s stand out. I like a lot of whitespace.
|
|
|
|
|
Also good if you get paid per line.
|
|
|
|
|
|
I try to have all my code visible without any horizontal scrolling.
To do this and still have pretty big lines I use a wide 22" monitor and lowered my font size to 8 (on VS 2008).
With this I find myself having all my code within the monitor limits without having bother about it (most of the times... )
|
|
|
|
|
What about the poor guy who is 55 and wears glasses that needs to maintain your code. Maybe you yourself?
|
|
|
|
|
What about him?
I'm not saying that our team works on small monitors with high resolutions, I'm saying that we use big monitors, currently 22" & 24".
My current configuration is 1680x1050 on a 22" DELL monitor.
Sure the resolution is high but as the monitor size is also above the usual you keep seeing thing on a normal size, no problem.
I can tell you that connected to the same computer I also have a 19" DELL with a resolution of 1280x1024 and I don't see any difference between them on the font size... I only have more workspace area on the 22" monitor.
Cheers!
Alex
|
|
|
|
|
I stuck to two general rules in programming:
1) One Statement per line (I don't usually make those insane multipurpose do all lines)
2) Descriptive Variable names.
Part 1 decreased column size and part 2 increases it. In code maintainability is more important that printable readability imho.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
If you don't ask questions the answers won't stand in your way.
Most of this sig is for Google, not ego.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: One Statement per line
Yes, but...
What's a statement? Isn't a compound statement a statement?
I don't stick to one line per statement (as is well-documented).
|
|
|
|
|
Welcome to the Year of the Ox !
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to stop bothering them and just go away?" - Balboos HaGadol
"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
|
|
|
|
|
Since I spend a great deal of my time working in stored procedures, I take the opportunity when I deem it necessary to update them for readability.
I DETEST having to scroll to the right to see what columns are being selected and then scroll back to the left to see what the query conditions are.
I especially get annoyed when I see an inline case statement in a select statement and it is all on one line.
Tim
|
|
|
|
|
I'll let code stretch out, but I do limit line length for documentation.
|
|
|
|
|
I always limit to between 80-100 chars maximum per line. Doesn't matter if it is being printed or not purely because it makes reading the code much more bearable.
Scrolling the screen horizontally for long lines breaks your chain on thought so keeping all the code right in front of you is better!
|
|
|
|
|
Paul Betteridge wrote: Scrolling the screen horizontally for long lines breaks your chain on thought so keeping all the code right in front of you is better!
I agree, although at times I may go to 120 chars just to be wild and crazy.
|
|
|
|