80. It shocked me to learn that some people don't hard-wrap their code at all. I ran into some github repository with comments which went on for 200+ characters and couldn't figure out what kind of maniac would inflict that upon the world.

I wrote a post about it which generated some responses, and it seems IDEs are to blame. Once you get into some of those environments, keeping things (relatively) narrow for the sake of others might just go out the window.

I covered it here, including a screenshot of what a typical dev session for me looks like: http://rachelbythebay.com/w/2012/08/31/lines/

When I code C for embedded hardware, I agree 80 is more than enough, but that's because that is a simple language and the artifacts always lead to smaller widths.

Now, try that in C++. You can loose 10+ chars to indentation (namespacing, etc) alone. I think the 80 chars puritanism is just plain idiotic, specially in some languages like Obj-C.

Take this kind of bureaucratic crap:

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(whateverChanged:) name:UITextViewTextDidChangeNotification object:nil];

If you start hard wrapping every long call you find you will end up with incredibly long files, filled with framework crap instead of useful information.

And yet, Google's Objective-C style guide (adopted by many) is uncompromising in its 80-character line length:

http://google-styleguide.googlecode.com/svn/trunk/objcguide....

Utter BS. "... We realize that Objective C is a verbose language and in some cases it may be more readable to extend slightly beyond 80 columns, but this should definitely be the exception and not commonplace"

Edit: One single attribution that crosses the 80 columns rule (4 levels of indentation - 4 spaces each)

placeHolderLabel.lineBreakMode = UILineBreakModeWordWrap;

The person who wrote that is obviously not fluent in Obj-C and even says the rule is 'controversial'.

javascript can have a lot of indents with all of the closures, so ... in those cases I might set the indent spacing to 2.

I still think that it's just common good manners to keep code to 80 chars, those languages should work better to not be so verbose.

Are you serious with these green terminal sessions? Wow....my eyes

Yes. My monitor can be astonishingly bright with other settings. I used to do black-on-white in the past, but that was on a different display which wasn't quite so powerful.

I can follow your aversion to IDEs (to each his own).

But foregoing a nice font and some basic syntax highlighting just seems masochistic.

To each her own, too.

For me, that is a nice font -- "9x15". It's one I deliberately selected instead of whatever the default would be.

Syntax highlighting drives me nuts, so I don't use it.

I used to be fanatical about 78 character width because we would print code from time to time and following wrapping lines can be a royal pain (ahh, the 90's).

Anymore I have been "ok" with 120 characters for most code, mostly because screen sizes have gotten so nice and I rarely print code anymore.

That said, I do still try and keep code around 80 characters wide where ever possible though, I just find the formatting and code legibility to be better in most circumstances. Also, I find this keeps people from nesting things too deep (C/C++/C# come to mind), because it becomes hard to follow the code, hence they start breaking code into more modular components.

My other reason, I sometimes work off only my laptop monitor and while it gets wide, I find myself scrolling left and right when code exceeds 90ish characters in width and that bugs me.

For object-oriented languages, long line lengths are signs that you are violating the Law of Demeter: http://en.wikipedia.org/wiki/Law_of_Demeter

I have a column usually set to 80 chars, or sometimes 100, and I manually make sure that it's not much longer than that unless it would hurt code readability to make a new line.

I try to have two windows open on my MacBook Pro 80-100 chars per line allows me to do that, most of the time.

It is a pet peeve of mine when developers try to fit as much on one line of code as possible. There are tools to compile code, you as a developer should try to make your code as human readable as possible, that is unless you like being the only one to maintain your code.

I'm not strict about column widths. If it starts to look too long (100+?), I check the column position and see if I shouldn't hard wrap it. Most of what I write isn't super long or super complex one-liners.

If I were working on a team based project, then I would absolutely adhere to a basic style guide regarding whitespace, line widths, etc.

I am not very strict about it. I generally try to keep it on my screen. If it starts to horizontally scroll, I will split it up. This used to come up a lot while crafting longer SQL statements. I just started writing them on multiple lines instead of out habit.

79, narrow columns easier to read (think newspaper), printable, keeps nesting to a minimum, and helps keep edits (in version control/diffs) reasonably surgical. On widescreen allows two windows to be side to side.

80 as well. Keeps stuff tidy across many monitors, and as a lucky bonus at work a NERDTree window and two 80 column windows fit perfectly on one monitor.

Edit: guess I should add I primarily work in Python, C, and Javascript.

I used to wrap to 79 because I used to write a lot of Python but once you get to the world of Java, 79 hampers readability. I still feel uncomfortable (and guilty) going beyond 79 though.

I'm pretty strict about 80. For whatever reason I find it easier to scroll down with my eyes rather than read across a long line.

I'm sure _everyone_ would find it easier to read scrolling down rather than horizontally.

I limit it to 132 characters, the standard line printer page width.

I follow it completely, regardless of language.

80, if possible. Some places dont follow that practice, though. 80 keeps it tidy.

80. So I can have 2 code windows side by side. Be it emacs or eclipse.