[minitech]

I break lines if it looks like they’re getting too long, where it feels right to do so. Setting a fixed number of columns causes people to align hanging lines to the right in my experience:

  some_example_code = LongTypeName(argument_one=1,
                                   argument_two=2,
                                   argument_three=3)

(pretend that’s 80 columns), resulting in this mess when I try to look at it in a narrower view:

  some_example_code = LongTypeName(argument_on
  ↳ e=1,
                                   argument_tw
  ↳ o=2,
                                   argument_th
  ↳ ree=3)

Turning off word wrap doesn’t help, because then it’s an equally painful constant two-character scroll. What does help is creating indented blocks where it feels right, and letting other lines just naturally be long.

  some_example_code = LongTypeName(
      argument_one=1,
      argument_two=2,
      argument_three=3,
  )

  some_example_code = LongTypeName(
      "just a string that happens to be long; some people introduce acceptable percentages of string literals for long lines, but it’s really not necessary. let word wrap take care of it!")

(Plus: specific column counts depend on the size of your indentation.)

[u801e]

> What does help is creating indented blocks where it feels right

Over the years, I've come to believe that using a hanging indent for alignment is actually better in terms of readability as opposed to aligning at a column after the opening parenthesis, brace, or bracket. It's also easier to type as well even if the editor doesn't provide an auto-indent facility (or if it's not configured correctly for some reason) since you only have to press TAB the same number of times to correctly position each formal parameter in the function definition.

As a side benefit, it also takes care of any alignment issues regardless of whether one uses tabs or spaces.

> and letting other lines just naturally be long.

Using the language's feature for string concatenation still makes it as easy to read:

  some_example_code = LongTypeName(
        "just a string that happens to be long; some people introduce " +
        "acceptable percentages of string literals for long lines, but it's " +
        "really not necessary. let word wrap take care of it!")

Another benefit of doing this is that it makes a unified diff and side-by-side diffs easier to read. Contrast the wrapped version when I add another sentence to the end of your example:

  diff --git a/tmp/wrapped b/tmp/wrapped
  index 972537b..27e3e31 100644
  --- a/tmp/wrapped
  +++ b/tmp/wrapped
  @@ -1,4 +1,5 @@
     some_example_code = LongTypeName(
           "just a string that happens to be long; some people introduce " +
           "acceptable percentages of string literals for long lines, but it's " +
  -        "really not necessary. let word wrap take care of it!")
  +        "really not necessary. let word wrap take care of it! Though unified " +
  +        "and side-by-side diffs may be more difficult to read")

versus the unwrapped one:

  diff --git a/tmp/unwrapped b/tmp/unwrapped
  index 284ef1e..db47f46 100644
  --- a/tmp/unwrapped
  +++ b/tmp/unwrapped
  @@ -1,2 +1,2 @@
     some_example_code = LongTypeName(
  -      "just a string that happens to be long; some people introduce acceptable percentages of string literals for long lines, but it's really not necessary.  let word wrap take care of it!")
  +      "just a string that happens to be long; some people introduce acceptable percentages of string literals for long lines, but it's really not necessary.  let word wrap take care of it! Though unified and side-by-side diffs may be more difficult to read")

With the wrapped version, you can more easily see what I added to the end of the line in your example. In the unwrapped example, I most likely would have to either scroll horizontally to read the entire line. If the line is soft-wrapped, then I would have to realize that the second line is part of the previous line and not a different context line (soft-wrapping is simulated by hard-wrapping right after the "for long lines," comma and the space after "difficult to " based on how blockquoted text appears a rendered comment):

  diff --git a/tmp/unwrapped b/tmp/unwrapped
  index 284ef1e..db47f46 100644
  --- a/tmp/unwrapped
  +++ b/tmp/unwrapped_more
  @@ -1,2 +1,2 @@
     some_example_code = LongTypeName(
  -      "just a string that happens to be long; some people introduce acceptable percentages of string literals for long lines,
  but it's really not necessary.  let word wrap take care of it!")
  +      "just a string that happens to be long; some people introduce acceptable percentages of string literals for long lines,
  but it's really not necessary.  let word wrap take care of it! Though unified and side-by-side diffs may be more difficult to
  read")

[minitech]

> Over the years, I've come to believe that using a hanging indent for alignment is actually better in terms of readability as opposed to aligning at a column after the opening parenthesis, brace, or bracket. It's also easier to type as well even if the editor doesn't provide an auto-indent facility (or if it's not configured correctly for some reason) since you only have to press TAB the same number of times to correctly position each formal parameter in the function definition.

> As a side benefit, it also takes care of any alignment issues regardless of whether one uses tabs or spaces.

That’s exactly what I said.

> Another benefit of doing this is that it makes a unified diff and side-by-side diffs easier to read.

Until you rewrap and it adds noise to the diff. I recommend a combined word/line diff instead.

Concatenation also hides whitespace problems. Not a serious error, but a very common one.

  "This ends with a period." +
  "But this doesn’t start with a space."