When writing code do you wrap text or not?

Question

I know a lot of people have their ide wrap lines in the code editor but i've always been of the thought that one statement = one line.

Thoughts?

Answer 1

I wrap between columns 72 and 76, indenting the next line one level more than the beginning of the statement.

Edit: To clarify, I wrap manually.

Answer 2

I never let the IDE do that for me because it's annoying. If one statement becomes too long or complicated to fit on one line of reasonable length, I'll wrap it myself thank you very much. This happens with largish format strings etc.

Answer 3

Scrolling is evil.

I (manually) wrap code in most cases.

Answer 4

I agree with you. Personally I think it's confusing to see a statement splitted across several lines but I also have listened people say that makes the code more readable ... Well not for me ;)

Answer 5

I wrap the text manually.

Big lines is very hard to understand because you have to scroll your screen all the time.

Answer 6

I would use Visual Studio's auto-wrapping but it seems to cause terrible pauses when editing code, very disruptive; so I have to manually scroll occassionally.

We don't manually split the lines at a fixed length, e.g. 80 characters because we have many developers, some who use widescreen displays, so that would be a waste of the horizontal bandwidth.

Answer 7

I have VS' line wrap on, but I also manually wrap where I think it works best. Been doing this since my VB days, and using C# has made it easier, if anything.

Horizontal scrolling is so counter-intuitive/-productive, and I work with other developers that may not have the same resolution/VS setup as I have, so the word wrap function comes in quite handy.

Answer 8

Scrolling sucks and if the IDE breaks the lines, it is always hard to tell if this is a line break of the IDE or of the code itself (you can usually see this in most IDE one way or another, but none will make it dead obvious). Also if a code line is so long that it breaks, it's hard to read if you have not written the code yourself. You need to parse it into tokens in your head and this is very hard with a single, huge line, thus I break them myself into tokens, making them easy to read (that is "easier to parse for the reader in his head").

Answer 9

Everything is said, but to make the point more graphically:

I really hate long lines that require you to scroll to the right to get a full understanding of the meaning of the code.

Scrollbar away.

Therefore I use linebreaks to break each line into managable pieces, such
that the user has an excellent overview which leads to quick understanding.

Answer 10

I manually wrap at substatements when the line gets too long. I indent to match the previous substatement of the same level. I have to admit that I use the whole width of the window I am working in, so other people with a less wide window might have to scroll sideways (or "soft wrap", if their editor supports it) occasionally.

Answer 11

I am not sure if you talk about auto-wrapping (display) or manual wrapping (hard-coded).

Anyway, I don't hesitate to split a line along several lines (double indentation for continuation lines, Eclipse style) if it goes way beyond column 100 (arbitrary number...). I don't want to scroll like a mad because a function call uses long identifiers or string concatenation, etc. which is common in Java, for example.
It is better to able to quickly scroll vertically the file and keep all code visible, without having text editor full screen in a large display and/or auto-wrapping activated (which can be necessary, eg. for log files).

Answer 12

Personally, I try to never write a line of code that's wider than my normal view in an editor (usually about 80 chars).

If the line I'm writing gets that long, I've probably done something wrong, and need to write it in shorter, easier-to-understand chunks.

Answer 13

The one place I do not wrap is long strings, such as log messages. The reason is that if someone is grepping the code for those later, a line break in the middle can lead to a trickier grep session. If a customer is seeing a certain log message and support needs engineering to solve the problem quickly, doing tricky greps is not on the fast track to success.

Otherwise, when I have the opportunity to influence code style, I try to get wrapping at 100 or 120 columns (justification being we have bigger monitors these days).

Answer 14

I manually wrap lines, but I tend to have a higher tolerance for long line lengths than the others indicate here. I usually allow about 130 characters on a line if it is a long function or class signature. I tend to be much more restrictive about the body of functions though.

When I wrap lines I rarely just wrap back at whatever character I'm on, but instead structure the code differently to clearly emphasize structure.

SomethingVeryLong foo = new SomethingVeryLong(arg1, insert(GettysbergAddress), arg3, arg4, foo != bar, ...);

likely becomes

SomethingVeryLong foo = new SomethingVeryLong(
    arg1,
    insert(GettysbergAddress),
    arg3,
    arg4,
    foo != bar,
    ...
);

This imparts visual structure to the resulting code.

I find it particularly important in C++ with templates, constructor initializers, large multiple inheritance clauses for mixins and template metaprogramming, etc.

Answer 15

I manually split lines to keep them less than 96 characters wide. I use this length because it is the longest line that my file printer utility can display (with line numbers) on 8-1/2" paper. This line length also displays nicely in all of the editors that I use.

When breaking lines, I like to pick "nice" places to break them up. As mentioned above, I also pick locations to split lines into substatements, and indent them.

When I started programming long ago, this wasn't a problem. Punched cards were all 80 columns wide, whether you liked it or not.

Answer 16

In the old days, I wanted to break all my lines before 80 characters. This gave me enough room to view two source files side-by-side (or the same file in two windows, side-by-side), which can be incredibly useful. For example, I could look at a function signature on one side while writing a call.

Today, several things have changed:

• My identifier names are much longer. I nvr abbr.
• My screen is much wider.
• IntelliSense does a good job of showing me the information I might wish for in the second window.

So, 80 columns doesn't seem like the right width, but I still know that horizontal scrolling is unpleasant.

When indent levels get deep, Extract Method is usually prudent, making the code clearer as well as narrower.

When an expression gets very long, storing intermediate results in temporary locals is a boon to debugging, is usually easier to read, and is also narrower.

When a method call is very long, depending on the situation:

• Refactor to group some of the parameters in to a new object, if that makes sense, or,
• Store intermediate results in a temporary local, if it's a nested call, or,
• Format to place one parameter on each line. Some folks put two short parameters on the same line, but I believe that strict consistency here is easier on the eyes.

Answer 17

I manually break lines so that I don't have to scroll horizontally, and the code is as readable as possible.. I always keep the first line of each individual statement at the proper indentation level for it's place in the code flow, and indent the rest of the lines of that statement a few characters more than that, so that it is easy to visually see which blocks of text represent each individual statement...

Using this approach often requires different indentation patterns for each statement I apply it to, so there's so single standard 'rule" I can mechanically apply to accomplish the most readable and most esthetically appealing result.. but the overall objective (I figure) is to place as much clearly readable and understandable code in view on a single screen as possible, without needing to scroll horizontally.

Answer 18

I would never use auto word-wrap, but I use a guideline in Visual Studio at column 120 to remind me that anything past that is too long.

You can only set this up via the registry as far as I know - in HKLM/Software/Microsoft/VisualStudio/x.x/TextEditor, create a new String value called Guides, and give it the value RGB(xxx,xxx,xxx) 119, where xxx are RBG values (they don't have to be the same). You'll need to restart Visual Studio if it's running.

Answer 19

I insert manual line-breaks. (I mostly write C#, Python and sometimes C++.) I aim for 76 columns but do sometimes make exceptions. The main reason for this that I haven't seen mentioned yet is for diff and (especially) merge tools. Perforce's p4merge will display three copies of the code side-by-side when doing a three-way merge. If you've used up all of your horizontal screen-space for one view of the code then you'll have difficulty doing a three-way merge.

Answer 20

I always wrap at 80 characters, because I find it easier to read, and detest having to scroll to discover content. I also believe I've seen research that says humans are better at scanning text of around 72-76 characters wide (which is why newspapers and magazines print in a columnar format).

Answer 21

I usually don't wrap. However, I try to make sure that nothing interesting happens too far right on any line.

Answer 22

You read code 1000x more than you write it. Everything that makes it easier to read code is worth the effort to do, even if it takes 900x longer.

(Disclaimer: 1000 is an arbitrary number chosen for impact.)