1

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?

4
  • "I can't help but feel that things like these add up." So prove it. Commented Jul 13, 2023 at 6:45
  • Do concatenated string literals really lead to run-time operations? The JVM is a marvel of optimization, it would surprise me if people hadn't thought of that one after 28 years. Commented Jul 13, 2023 at 8:06
  • @KilianFoth doing string concatenation in Java loops may indeed lead to runtime problems. I myself broke my nose on that several years ago (was using Java 7 or 8 back then)
    – gnat
    Commented Jul 13, 2023 at 8:22
  • 2
    YMMV, but I do not activate word wrap by default in my IDE, because it can really make it hard to follow visually which code is still "on the same line" and which is not. Hence your "word wrap" argument does not convince me.
    – Doc Brown
    Commented Jul 13, 2023 at 9:17

3 Answers 3

2

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.
1
  • +1, people aren't aware enough that i18n is usually a win even if you're not supporting more than one language. Commented Jul 13, 2023 at 8:07
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.


Haste bin link died so promoting this comment to answer text:

As an example, breaking var validationMethod = library.GetType().GetMethods().FirstOrDefault(method => string.Compare(method.Name, _propertyName, StringComparison.InvariantCultureIgnoreCase) == 0); into multiple lines (in particular, the lambda expression) gets really awkward really fast. The only logical place to line break is at the FirstOrDefault().

Robert Harvey

var validationMethod = library
  .GetType()
  .GetMethods()
  .FirstOrDefault(
    method => string.Compare(
      method.Name, 
      _propertyName, 
      StringComparison.InvariantCultureIgnoreCase
    ) == 0
  )
;
8
  • Almost agree. A more practical limit is however many characters will comfortably fit the width of a 1920 pixel wide screen with room to spare for the project explorer window in your programming tool of choice (it's about twice the limit you propose), with exceptions for things like write-only regexes. The 80 column rule goes all the way back to Hollerith cards, and is essentially irrelevant. Commented Jul 13, 2023 at 22:00
  • @RobertHarvey it remains the standard. Technical history aside, humans read columns faster than rows. That’s why newspapers use columns. If you find IDE windows on either side wasteful do what I do. Rotate your monitor. Commented Jul 13, 2023 at 23:49
  • @RobertHarvey but remember, I never said everyone must use 80. I said what I’d expect in MY 80 column shop. Commented Jul 13, 2023 at 23:54
  • As an example, breaking var validationMethod = library.GetType().GetMethods().FirstOrDefault(method => string.Compare(method.Name, _propertyName, StringComparison.InvariantCultureIgnoreCase) == 0); into multiple lines (in particular, the lambda expression) gets really awkward really fast. The only logical place to line break is at the FirstOrDefault(). Commented Jul 14, 2023 at 11:58
  • @RobertHarvey Try this. Let me know what you think. Commented Jul 14, 2023 at 16:14
0

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.

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