One line per idea - the feedback

2014-10-06  |   |  writing  

I wrote a bit more than a year ago on how to wrap lines for markup languages. I promised to give feedback on this experiment and specifically the use of one line per idea or clause.

Remember that to me, using one line per paragraph is problematic:

  • navigating through it is a bit cumbersome
  • reviewing a git diff is annoying when you need to scroll horizontally
  • editing one character leads to the whole paragraph as being seen edited in your favorite diff tool (at least if it is not that smart)

I am sad to say that the one line per idea concept does not work for me despite its big advantages on paper and its elegance. In practice, forcing myself to split each sentence in separate ideas lead to a slight writing slow down and cognitive dissonance. In a nutshell finding the natural split is not as easy as it sounds. And I could not really convince at least some of my colleagues enough of the benefits of this rule.

I settled for the following. One line per sentence. If the sentence is too long, one line per idea. And I won't mind if someones breaks the sentence at "odd" places.

It's one of those nice ideas that are not worth their cost.


One line per idea

2013-08-08  |   |  writing  

Now that most of my writing is done in a markup language like Markdown or Asciidoc, and now that I do version my writing in an SCM (Git to be specific), I have been wondering about how to spit text. I have considered 80 characters per line (plus auto wrapping) or one sentence per line.

Line wrapping

Automatic line wrapping is aesthetically pleasant but if I change the very beginning of a paragraph, my whole paragraph is marked as changed in diff.

 The problem with the former is that if I
-change the very beginning of a paragraph,
-my whole paragraph is marked as changed
-in diff. The problem with the latter is
-that sentences tend to be quite long and
-thus wrap and changes are hard to track
-to even though it is easier than with the
-former approach.
+happen to change the very beginning of a
+paragraph, my whole paragraph is marked
+as changed in diff. The problem with the
+latter is that sentences tend to be quite
+long and thus wrap and changes are hard
+to track even though it is easier than
+with the former approach.

One line per sentence

One sentence per line partly solves the diff problem but sentences tend to be quite long (and thus wrap) and changes are not fully obvious to track even though it is easier than with the line wrapping approach.

-The problem with the former is that if I change the very beginning of a paragraph, my whole paragraph is marked as changed in diff.
+The problem with the former is that if I happen to change the very beginning of a paragraph, my whole paragraph is marked as changed in diff.
 The problem with the latter is that sentences tend to be quite long and thus wrap and changes are hard to track even though it is easier than with the former approach.

One line per idea

I came across this post which proposes to have line breaks between ideas (punctuation is a good indicator but clauses is probably even better).

 The problem with the former is that
-if I change the very beginning of a paragraph,
+if I happen to change the very beginning of a paragraph,
 my whole paragraph is marked as changed in diff.
 The problem with the latter is that
 sentences tend to be quite long and thus wrap

This offers the advantages of the line per sentence without its disadvantages. What's interesting is that this approach has been proposed at least as far as 1974 :) and focuses on changes rather than the initial blurb. Clever!

That's on paper at least. I will try this approach from now on and see if that works for me.


Name: Emmanuel Bernard
Bio tags: French, Open Source actor, Hibernate, (No)SQL, JCP, JBoss, Snowboard, Economy
Employer: JBoss by Red Hat
Resume: LinkedIn
Team blog: in.relation.to
Personal blog: No relation to
Microblog: Twitter, Google+
Geoloc: Paris, France

Tags