8

Possible Duplicate:
C# coding style - line length / wrapping lines

Is there a widely accepted coding convention for C#, and is there a suggested maximum line width?

The 80 characters per line rule is very common, but I think it is a bit too short for C# with generics. So is there any other convention for C#?

Solution: My team an I decided to go with 100 characters per line and it seems to be a good line width.

Community
  • 1
  • 1
deamon
  • 89,107
  • 111
  • 320
  • 448
  • 1
    you may find [this Helpful](http://stackoverflow.com/questions/2151836/c-coding-style-line-length-wrapping-lines) – V4Vendetta Mar 23 '11 at 09:02
  • 1
    What fits on your screen works well. If you need to wrap over multiple lines then format it nicely so that it is readable. If you need to fit more on a line then go for a smaller font. Personally i would rather lines extend off the end rather than being too short - for some reason that bugs me. – slugster Mar 23 '11 at 09:04
  • `using ShorthandName = System.Collections.Generic.List>;` –  Mar 23 '11 at 12:16

4 Answers4

13

If I went with "what fits", without much thought other than that, I would be cramming 60 lines into a function at 260 characters per line, and could still argue that "it all fits on my screen". It does, and I'm not using a ridiculously small sized font either. (9 pt Courier New, 24-inch widescreen monitor at 1920x1200, with basically the whole screen real estate devoted to code; the solution explorer, code definition window, output window, error list and so on are on my second monitor.)

Everyone is going to have their own opinion, and personally I think 80 character line widths are a bit off in the other direction these days, but depending on exactly what it is about, I try to keep myself under 100-120 characters per line, including indentation. If it gets much longer than that, there's probably parts in it that can easily be broken out and put on separate lines in ways that improve readability.

Because that is what it really is about. Readability. I don't really care if you use 60 characters per line or 200, but when I have to work with your code, it had better be easy to read and easy to tell at a glance what it does.

Also, try to chunk your code in ways that will provide meaningful diffs that are, again, easy to read. That's another rule of thumb I try to stick to; if I compare two sets of files, I want to see the changes that actually matter, not kilometer-long lines where the only difference is a single character change (which may very well be a very valid change, but is difficult to find in such a behemoth).

user
  • 6,897
  • 8
  • 43
  • 79
2

I have two monitors, one is 26' and the other 22'. I use the smaller one to place utility windows as File Structure, Class view, Code definition, Object browser, To-do Explorer, Output, Error list, Pending changes (Ankh plug in) and so on. I leave the main window just for code and the project browser, so I told ReSharper set my line width to 160 characters (just in case I'd need some line to be that long). Normally I won't exceed 120 characters which is the length I feel most comfortable with. I'd feel really dumb if I had to work on this monitor with fewer than that.

The 80 characters per line made sense back in the day, when it was the standard width for monitors in text mode.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Trap
  • 12,050
  • 15
  • 55
  • 67
1

I try to ensure that a function fits on my screen without any scrolling (vertically or horizontally). Of course, everyone has different sized monitors, running at different resolutions and the layout of their toolbars/solution views/output windows etc. is different so it's hard to guarantee that across everyone in the team's systems. Still it's a useful guideline.

Jackson Pope
  • 14,520
  • 6
  • 56
  • 80
  • "ensure that a function fits on my screen without any scrolling (vertically or horizontally)" - horizontally - that's fine, I can do that too. But vertically? I can't even imagine that. But I liked your idea, so +1 – Sнаđошƒаӽ Oct 25 '16 at 06:18
  • It's a guideline to break methods down. If it's getting very long, pull out some of the content into another suitably named function, so the original method is made of calls to methods that do the work and it can be clearly understood what it does by looking that the names of the methods it calls. – Jackson Pope Oct 25 '16 at 09:30
  • Sounds very very nice to me. And I would very much like it to be able write codes that way. – Sнаđошƒаӽ Oct 25 '16 at 10:19
0

I'd go with what fits. I generally try not to extend too far off the screen I'm working on. Sometimes artificially narrowing statements by putting them onto multiple lines is no more clear than having a longer single line.

It's a very subjective question!

Nick
  • 25,026
  • 7
  • 51
  • 83