

Ask HN: Do you limit your code to a certain line width? - rustc

If yes, then
1. How much?
2. How strict are you in following the limit?
3. What do you think about this?<p>I'm interested because I was trying to format code to 80 chars wide, but I find that a little less. I think between 100-110 is a sweet spot for readability.<p>PS: I write Ruby/JS.
======
rachelbythebay
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/>

~~~
eduardordm
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.

~~~
rizwan
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....](http://google-
styleguide.googlecode.com/svn/trunk/objcguide.xml?showone=Line_Length#Line_Length)

~~~
eduardordm
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'.

------
davismwfl
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.

~~~
eduardordm
Programmers using line lengths as a reason to building modular software is
something that I never heard in my life, not even as a joke.

~~~
yen223
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>

------
jdavid
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.

------
caw
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.

------
ohashi
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.

------
loungin
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.

------
mixmastamyk
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.

------
eshvk
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.

------
Pinatubo
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.

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

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

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

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

I follow it completely, regardless of language.

