To enforce column limits on long strings?

Question

We're trying to update our style guide (using google's guide as a starting point) and I'm currently in the middle of a debate with my colleagues about column limits. I believe we're all in agreement that they're generally a good thing, however I'm upset that a string (or simple string template) assignment would necessarily be split (with concatenation operators and new lines) if we enforced this style rule.

For example, I have a simple string assignment for a feedback message that is ~250 characters long which would now get broken up into several lines. I am of the opinion that any modern editors with word-wrap should handle this fine, and the result would actually be more readable. Some thoughts to consider:

• Enforcing this means we would be adding unnecessary (some may say trivial) run-time operations, but I can't help but feel that things like these add up.
• Adding " + [line break][indent]" in the middle of a long string is IMO more detrimental to readability than just letting it continue on and word wrap.
• Long string assignments such as my feedback message I feel resemble more closely books, emails, or news articles, rather than loops, conditionals, and function calls. Most places that deal with natural language (not code) on a screen don't enforce maximum line lengths, they just word-wrap and the scroll bar gets shorter or longer.
• Is it worth making an exception on lines where the last item is a long string?
• Should long strings (or strings in general) be moved off into a separate file/directory, where this particular rule is not enforced? (Such as is the case for some internationalization translation files)

Is there a general consensus on this topic, or is it just not worth debating and I should move on to "more important" things? Am I in the minority by thinking this way?

Answer 1

I don't believe there is general consensus on this topic.

But if your application supports internationalization, then you could use those tools to your advantage. Especially if the i18n tools use the full original text as a key, like gettext does.

In that case, you could write short descriptive messages in your code (in "computerese") and provide the long, user-friendly, message as a translation to English. The advantages here are:

• Fewer issues with long lines due to very long strings
• Other translations don't get invalidated due to wordsmithing on the English text.

Answer 2

The absolute number one rule on splitting long strings is:

Don't do it in the middle of my search for that string!

I can't tell you how many hours I've wasted hunting for the right search string to find a string that some code is showing me that I can't find because some goofball split it at some silly ass point.

If you were in my shop I'd stick you with a hard 80 column limit and tell you to split strings where it makes sense to split them. No turning off your brain. No letting the IDE do it for you. Sit down and figure it out. Long strings have punctuation. Use it.

Whitespace should show structure. Word wrapping⁼ shows laziness.

If you can't solve the problem under that tyranny then move the string somewhere else. Don't stick my code with a horizontal scroll bar. They're evil.

It's work. But it's worth doing. Don't expect the style guide to do it for you.

_{This rant brought to you by a back end coder who was not thinking about html, xml, or any of those other webby domain specific languages that are hard to look at no matter what you do.}

Answer 3

We're trying to update our style guide (using google's guide as a starting point)

Do you also maintain a workplace holy book, using the Bible as a starting point?

Is there a general consensus on this topic [of line lengths for string literals], or is it just not worth debating and I should move on to "more important" things?

I don't think it's generally considered a very pressing issue.

My personal inclination would be to split a long string over multiple lines, so that all text remains visible under the typical viewing conditions, and only vertical scrolling is required.

It's worth mentioning that in natural language we split lines in order to keep the text within our central vision and other ergonomic aspects - it's not just arbitrarily determined by the width of a paper page.

But I don't think I'd be fully consistent in all cases in code (particularly if the excess was only small), and crucially, I doubt it would ever be on the agenda for collective discussion.

It's highly important that coders pay attention to style as a general aid to readability (especially in languages that allow a wide variety of formatting), but it's hardly ever important that two programmers be exactly aligned on the finer points.

I'm not really aligned with myself on the finer points from one day to the next, and from one situation to the next.

What is important is that coders pay enough attention on their own initiative that the code is sufficiently tidy without someone having to follow them around, and that the code is reasonably readable as-is and doesn't have to be completely reformatted to be read by the next reader.

And obviously once there's a reasonable body of code written to a particular style in one particular module, you expect others maintaining the same module later to fall in with the general thrust (without treating the entire work of a shop as a single "module").

If you're finding that you're getting inconsistencies in style at the code file level in brand new code, or within any reasonably narrow scope, that perhaps implies that multiple people are working too closely - like having two carpenters sawing the same plank of wood at once.

In other words, the solution is to distribute the workers onto different tasks of reasonable granularity, not to try and devise a fixed rhythm for sawing so that the plank stays still whilst each worker cuts their end. The hassle of such coordination would far exceed the benefits of having both ends of the plank cut concurrently.

Once people are distributed on reasonable tasks, the question is not aligning all styles, but whether each person's style is fairly readable and workmanlike.