Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing one sentence per line

sive.rs

Post reply on HN
Print view View original

291–300 of 307 posts

Re: Writing one sentence per line

#291

Post by [deleted] »

Jaruzel wrote: post #56
wheybags wrote: post #53

Slightly off topic, but a pet peeve of mine is how you don't get a real line break in markdown when you insert a newline. Sometime I want a line break without a vertical apace for a new paragraph, I can't be the only one here! I know I can normally just add a br tag, but that looks nasty when you read it as plain text.

Markdown allows you to inline HTML, so just use the tag for a newline. Edit: Oh come now... Editing your post to also say what I replied, then voting me down is poor sportsmanship old chap.

[deleted]

Re: Writing one sentence per line

#292

Post by Loranubi »

Groxx wrote: post #256
hinkley wrote: post #239

Earlier quoted context omitted.

I think we need to start changing this. In an era of language servers, perhaps our diff tools should be semantic instead of line based. I get so tired of seeing diffs where I add a function and the diff shows that I added it inside the previous function instead of between them, because it starts the diff one line too early.

Debuggers and stack traces too. Logic is not line-based. When you get a NPE on a line containing `thing.method(x.y.z, q(), w.e().rty())`, which item is it on? Type information is insufficient, there could be multiple of the same thing on the same line. Some debuggers are smarter ("step to cursor" sometimes goes to in-line locations), but many are not, and most languages I've seen will give you precise compile-time er…

Python 3.11 provides this information at runtime. https://docs.python.org/3.11/whatsnew/3.11.html#enhanced-err...

Re: Writing one sentence per line

#293

Post by layer8 »

luhn wrote: post #209

One big advantage not mentioned in the article particularly relevant to this audience: git diffs (or your VCS of choice). One sentence per line means diffs will operate per-sentence, rather than per-paragraph. This way the diff can capture the restructuring of the paragraph (adding/removing/replacing a sentence), which gives much more insight than swapping out the paragraph wholesale. It also means minor changes (e.g…

> One sentence per line means diffs will operate per-sentence, rather than per-paragraph.

It isn’t necessary to have each sentence on a single line in order to achieve that. It’s sufficient to have a line break after each sentence, but you may also have additional line breaks in the middle of a sentence. That’s how I format plain text when diffs are relevant.

Sometimes it also makes sense to not have a line break between closely related (and possibly short) sentences. In the end it’s the semantic coherent unit of thought that counts, not the syntactical sentence-ending period or full stop.

Re: Writing one sentence per line

#294

Post by account42 »

spartanatreyu wrote: post #281
hinkley wrote: post #239

Earlier quoted context omitted.

I think we need to start changing this. In an era of language servers, perhaps our diff tools should be semantic instead of line based. I get so tired of seeing diffs where I add a function and the diff shows that I added it inside the previous function instead of between them, because it starts the diff one line too early.

The problem with diffing goes further than most people think. It's not a problem itself, it's a symptom of a deeper problem: we represent all of our code as plain text. We have built almost everything around plain text, for a long time now. The few things that aren't built around plain text tend to require either proprietary software or open software that seldom lasts more than a decade. Yes, plain text has impressiv…

There is nothing preventing you from pretending that a source file is not plain text but rather a bespoke AST encoding that just happens to look like plain text. The only advantage to using a different AST encoding is parsing speed that that by no means offsets the enourmous advantages that a plain text encoding gives you for something that is edited by humans.

Re: Writing one sentence per line

#295

Post by account42 »

dahfizz wrote: post #247
hinkley wrote: post #239

Earlier quoted context omitted.

I think we need to start changing this. In an era of language servers, perhaps our diff tools should be semantic instead of line based. I get so tired of seeing diffs where I add a function and the diff shows that I added it inside the previous function instead of between them, because it starts the diff one line too early.

Yes! I find `git diff` to be the most annoying thing about git. I can be pretty forgiving of the clunky UX, but the diff output is just wrong. People often say of git, "The porcelain is bad but the plumbing is good". The opposite is true for digging, IMO.

Well, `git diff` is part of the porcelain. The git model doesn't work on diffs, it works with complete trees (sometimes stored as deltas, but that is an implementation detail). Diffs are for the user because they make it easier to see the difference compared to just having the old and new copy show. There is nothing preventing git diff from being changed to use semantic information when calculating the diffs shown.

Re: Writing one sentence per line

#296

Post by erellsworth »

eesmith wrote: post #132
erellsworth wrote: post #87

Tangentially related: "Omit needless words." -William Strunk, The Elements of Style Highly recommended book for anyone who wants to be a more effective writer.

Have you read any of the criticism of the book? Its Wikipedia entry quotes Pullum: > The book's toxic mix of purism, atavism, and personal eccentricity is not underpinned by a proper grounding in English grammar. It is often so misguided that the authors appear not to notice their own egregious flouting of its own rules ... It's sad. Several generations of college students learned their grammar from the uninformed bo…

Sure, I wouldn't recommend anyone ever take any writing guide as some kind of scripture to be followed dogmatically. As with any art, there are no real rules, only guidelines.

Unless, of course, you're taking a class, in which case the rules are whatever the professor says they are. There's a reason academic writing isn't often very enjoyable to read.

Re: Writing one sentence per line

#297

Post by danw1979 »

I love these small but significant improvements that are kind of obvious but were hidden in plain sight.

For years I didn’t even consider there was an alternive to writing in paragraphs, despite using git and markdown daily.

Re: Writing one sentence per line

#298

Post by eesmith »

erellsworth wrote: post #296
eesmith wrote: post #132

Earlier quoted context omitted.

Have you read any of the criticism of the book? Its Wikipedia entry quotes Pullum: > The book's toxic mix of purism, atavism, and personal eccentricity is not underpinned by a proper grounding in English grammar. It is often so misguided that the authors appear not to notice their own egregious flouting of its own rules ... It's sad. Several generations of college students learned their grammar from the uninformed bo…

Sure, I wouldn't recommend anyone ever take any writing guide as some kind of scripture to be followed dogmatically. As with any art, there are no real rules, only guidelines. Unless, of course, you're taking a class, in which case the rules are whatever the professor says they are. There's a reason academic writing isn't often very enjoyable to read.

Then Strunk and White isn't a good initial reference as they are pretty dogmatic in their many rules. White referred to "the remembered sting of [Strunk's] kindly lash", and likened the rules to a sergeant "snapping orders to his platoon." How are readers supposed to understand those orders aren't real?

I don't understand the relevance of "academic writing" as 1) Strunk and White is widely recommended to authors in general, 2) 10+ million copies sold aren't mostly going to academia, and 3) examples from the book show a bias against what Wikipedia at https://en.wikipedia.org/wiki/Academic_writing characterizes as "academic writing".

Eg, "The Elements of Style" really does not like the noncommittal academic writing style of the following (quoting from https://archive.org/details/elementsofstylew00stru/page/14/m... ):

> The Taming of the Shrew is rather weak in spots. Shakespeare does not portray Katharine as a very admirable character, nor doe Bianca remain long in memory as an important character in Shakespear's works.

and instead prefers:

> The women in The Taming of the Shrew are unattractive. Katharine is disagreeable, Bianca insignificant.

Re: Writing one sentence per line

#299

Post by april_22 »

ghaff wrote: post #192
swamp40 wrote: post #174

I have to do this in my emails. Most people just ignore the second and third sentences in a paragraph. No idea why, drives me crazy - but this does help. You can tell they don't read them because they ask questions that were answered in them.

>No idea why Because that tends to be how people skim. If the first sentence of a paragraph doesn't catch their attention in some way, they subconsciously assume that the rest of the paragraph (which is presumably related) doesn't need to be read.

Plus attention spans are getting shorter. I feel like it's getting harder to simply read for more and more people.

Re: Writing one sentence per line

#300

Post by speleding »

luhn wrote: post #209

One big advantage not mentioned in the article particularly relevant to this audience: git diffs (or your VCS of choice). One sentence per line means diffs will operate per-sentence, rather than per-paragraph. This way the diff can capture the restructuring of the paragraph (adding/removing/replacing a sentence), which gives much more insight than swapping out the paragraph wholesale. It also means minor changes (e.g…

Another advantage not mentioned: it helps you avoid overly long sentences. I use this technique and have a habit of rambling on. If I hit the right margin of my text editor I know I should try to split the sentence.
Post reply on HN