User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am working on an application where code will be shown on a mobile device. This gives us a constrained width as horizontal scrolling isn't a desired choice for code with long lines. So we have to force the text to wrap in the code block. We have two options:

Break word - where only whole words break. This has the advantage of easily seeing whole words, but has situations (as shown here) where it is visually less than ideal.

break word example

Break all - where it breaks in any point regardless of whether this is in the middle of a word or not. This tends to look better (subjective), but it could be problematic with longer words (as shown here)

break all example

Which option is better for programmers, and why?

share|improve this question
Reading wrapped lines of code is one of the things I truly hate most. I rely so much on code indentation, line breaks become really visually and mentally stressful and distracting. – Mark Garcia Feb 7 '13 at 4:28
Is there an option to have wrapping off altogether? It might not be ideal for everyone but as Mark points out above many people would prefer this over line wrapping (i would even hypothesize that it is easier to horizontally scroll on a touch-screen device than on a desktop-size device - although naturally larger devices could contain more items on a line so horizontal scrolling would be limited anyway). – JonW Feb 7 '13 at 9:25
@JonW We tested that, and it was problematic in many situations, especially considering the application. We also have an inline code element, which can't scroll horizontally and needs to break with similar logic. – JohnGB Feb 7 '13 at 12:21
I know this doesn't answer your question, but did you experiment with using a smaller font? Or implement something similar to the fish-eye lens technique they use in InfoVis (you effectively enlarge certain portions of the content, and heavily reduce the size of the surrounding parts). – CJ Franken Feb 8 '13 at 21:17
@CJFranken We didn't consider them as it's essential that the code block is quickly and easily readable. Anything that requires interaction to read hurts the UX for us. – JohnGB Feb 8 '13 at 21:24
up vote 14 down vote accepted

As a programmer, I prefer the line breaking to happen at the boundaries of words (assuming your assessment that line breaking is needed is correct).

However, I would change the way you break. Instead of continuing at column 0, I think you should continue at the same column as the line you are breaking, and you should indicate somehow that it is not a real line on its own, but a continuation of a previous line very clearly. Just the line numbers don't quite cut it, I think. Something like:


download bmml source – Wireframes created with Balsamiq Mockups

A remaining problem is that a symbol like a space is going to be very hard to spot at a line break. I think that needs thought, because such a symbol may be very relevant in code. Perhaps if a space was used as a position to break at, it should get some special symbol as well so it stays visible at either the end or the beginning of the line.

share|improve this answer
There is already zebra striping and numbers to make it clear that the like is part of a previous one rather than a new line. What else would make that clearer for you? – JohnGB Feb 7 '13 at 14:39
I added an example showing small symbols directly in front of the lines that are a continuation of the previous line. – André Feb 7 '13 at 14:57
That is a really interesting approach that I have not seen before. Thanks. – JohnGB Feb 7 '13 at 15:13
This I like, as I program a lot. – Toni Leigh Nov 20 '13 at 9:32

Breaking up words/names is a bad idea for the simple reason that it's hard to tell where the function name begins and where it ends. Names can be abstract which makes them even more difficult for the brain to stitch back together.

The first just feels more natural and although still difficult to read, you quickly can understand that text is wrapping and begin to decipher. The second, is almost impossible to decipher. I would copy and paste the code somewhere else just to double check what the full function name is.

share|improve this answer

One option is to set a minimum width on the code container and let the user scroll horizontally. Code that wraps unexpectedly is confusing at best, and in languages like Python it will appear completely broken. (This would be overflow-x: auto or scroll on the code element's parent in CSS.) 80 monospaced characters is often the default line length.

share|improve this answer
As I have stated already, horizontal scrolling is not at option, so given that it is not an option I'm trying to make the best of a non-ideal situation. – JohnGB Feb 7 '13 at 14:41
Whoops, I must have overlooked that bit! – Sam Pierce Lolla Feb 7 '13 at 18:44

I have never heard of any wrapping algorithm that would break up words on anything but syllables (or soft hyphens). So breaking up a words at any arbitrary character is certainly not advisable.

For programmers words in code are identifiers or operators etc. They only have meaning as a whole. So in this contexts even breaking up on syllables is ill-advised.

share|improve this answer

Make a toggle: Linebreak [yes] or [no].

Depending on the programming language being displayed, inserted linebreaks will alter the execution of the code. Once you do break the code onto a new line, indicate this by adding the linebreak character at the end of the line.

With a toggle you will be able to give the user of your application the option of making the text wrap, or not.

Additionally, display line numbers. When a line is wrapped, the 2nd line should not be a new line in the line number display, which also ensures the reader knows it is supposed to be all on one line.

share|improve this answer
That doesn't really answer the question about what to do when linebreak is on though - should it break anywhere or only at word level? – JonW Feb 7 '13 at 9:28
Word level, preferably. Makes things more readable in my opinion as a coder. Breaking on any character can disrupt the flow of words being typed out. That said, concatenations should be kept together, e.g. "" or "object->property", don't break on the "." or "->", especially not in between the "-" and ">". – MHD Feb 7 '13 at 11:18
@MHD adding a toggles would not be an option for this. I won't go into detail why as it would derail the question a bit. – JohnGB Feb 7 '13 at 12:24
@JohnGB If this is for touch devices you could use a multi-finger tap, or a (pinch) gesture, as a hidden toggle. The ability to disable wrapping, even temporarily, would in many situations be a real boon for understanding the code. – Koen Lageveen Jun 1 '13 at 9:56

Boy is this a rock and a hard place. Definitely keep words intact. No programmer is going to like this (as is already clear), too much info is being removed by the indentation being mucked up. Breaking words doesn't solve this and it does add other problems.

To make the best of a bad situation you need to clearly delineate lines. Your examples use zebra stripes to delineate lines but for some reason I think I prefer simple 1px lines at the bottom of each line - I can't explain why I.

And that looks like Python code in your example. You do realize that in Python by changing the indentation you're changing the meaning of the code? Most languages don't use indentation as a syntactical element but Python is one of the languages that do. In most languages mucking up the indentation is a major inconvenience (but the precise meaning is not changed) but in Python it's destructive (the meaning is changed, or more likely the code could be rendered invalid). So if this code display is to support Python I think you might want to rethink the path that led to these restrictions (like no horizontal scrolling, etc.), I think it would be really disastrous to show Python code with its indentation messed up.

share|improve this answer
How was the indentation mucked up in that code? The text overflowed the edge, but no additional indentation was used. – JohnGB Feb 8 '13 at 12:38
@JohnGB - sorry for the delay. It is possible to add a line break that will change the indentation. If the indentation great and the line is broke with nothing to the left of the break but whitespace, the code is "broken". Rare case, nevertheless.... – obelia Feb 10 '13 at 17:18

I know the good way of wrapping for humans, including developers. The first way. You don't break words. If you do break words, they are not readable anymore. When reaching the wrap point, you may make it clearer that the line continues, by putting at the right a symbol like an arrow ⤶. Nice text editors do that.

share|improve this answer

I'm a programmer, and therefore entitled to have an opinion: use the second way ("break all" wrapping).

Why? Well, there are several reasons. First of all, the first option won't always be accessible. Someone will come up with another_veeeeery_long_function_name, which won't fit on the line even if there is nothing else on that line.

Secondly, in programming languages (especially Python) white-space is important. In particular, in Python each newline starts a new command, therefore inserting newlines liberally really hurts readability. In the first example I would have guessed that def by itself is meaningless, so probably a word-wrap have occurred. But there are examples when the wrapped expression may be misinterpreted as two separate commands: for example, consider x = 1, very_long_function_name() (in this case x = 1, would be a perfectly valid statement which creates a single-element tuple). Of course, line numbers and stripes add some cues as to the line boundaries, but visual appearance of a line running into the window boundary is a much stronger cue.

Now, there is of course the concern that identifiers broken at arbitrary points will be unreadable. To improve affordance, I'd suggest the following three changes: (1) reduce the interline distance within the word-broken line (so that line distance between "logical" lines is larger than interline distance between "visible" lines). (2) add hyphenation marks (or any other marks) indicating that the identifier was broken — this should be unambiguous since in most languages identifiers cannot contain hyphens, and their color shall differentiate them from the minus signs. (3) wrapped lines should continue at the same indentation level, so that block boundaries can be easily followed.


share|improve this answer

If there are places in the code where whitespace would be semantically insignificant, one should limit like breaks to such places when practical. If there are no such places, or if the distance between them will often be more than about 1/3 the length of a line, then I would suggest using a monospaced font with fixed-length lines and using some means to show which lines on screen are continuations of previous lines (e.g. precede each "real" line with a line number in a smaller font; the absence of a line number will indicate that a line is just a continuation of the previous one).

Character-based line wrapping in the fashion of many Microcomputer BASIC systems is often ugly, but small screens don't always offer any really good alternatives. One good thing about such systems is that if one has a fixed line length of e.g. 24 characters, one can use that to judge the length of a string that should be e.g. exactly 80 characters: it should be three lines plus eight characters. Systems which use proportional fonts or word-based wrapping are often helpful, but can make such character-counting tasks much more difficult than those which show a fixed number of fixed-width characters per line.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.