Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

all: inconsistent hyphenation #21327

Open
josharian opened this issue Aug 6, 2017 · 6 comments

Comments

@josharian
Copy link
Contributor

commented Aug 6, 2017

Grepping for //.*[a-zA-Z]-\n (see CL 53510) yields some examples of phrases that are inconsistently hyphenated in the tree. Two prominent ones:

  • "floating-point" vs "floating point"
  • "run-time" vs "run time"

Low priority, but we should pick one and use it consistently. (And also do a more targeted grep to find other hyphenation inconsistencies.)

@josharian josharian added this to the Unplanned milestone Aug 6, 2017

@bcmills

This comment has been minimized.

Copy link
Member

commented Aug 6, 2017

We should also be consistent about how to punctuate em-dashes: we currently have a mix of two or three hyphens, with or without AP-style spaces.

The typographically-correct thing to do would be to use u+2014 (em dash) consistently, in which case I would suggest also using spaces: many editors render an em-dash as a single-width character in fixed-width fonts, so a single em dash without spaces often appears too narrow.

(But even if we don't use the em dash, we should be consistent about spacing.)

@bcmills

This comment has been minimized.

Copy link
Member

commented Aug 6, 2017

Finally, should we use typographically-correct en dashes instead of hyphens for things like algorithms (Miller–Rabin), ranges (a–z, 0–9, R7–R25), and contrasting compounds (Child–Sibling order)?

(http://www.thepunctuationguide.com/hyphen-and-dashes.html is a great reference on the various dashes and their usage.)

@josharian

This comment has been minimized.

Copy link
Contributor Author

commented Aug 6, 2017

should we use typographically-correct en dashes instead of hyphens

Yes!

a single em dash without spaces often appears too narrow

That's a pity, but em dashes are properly used without spaces.

(But even if we don't use the em dash, we should be consistent about spacing.)

Yes, please.

On the en/em dash front, an alternative is to use two or three hypens and teach godoc to combine them. But I'd rather just use the rune to begin with.

(I just started pondered writing a tool to reflow comments, using some heuristics to trade off between semantic line breaks, reasonable line length, consistent line length, and punctuation niceties...and decided to beat a hasty retreat. It would be kind of awesome for Go to be the language with the best automated comment layout engine, though.)

@bontibon

This comment has been minimized.

Copy link
Contributor

commented Sep 26, 2017

Another one to add to the list is UTF-8 encoded vs. UTF-8-encoded.

@bcmills

This comment has been minimized.

Copy link
Member

commented Jun 5, 2018

@bontibon I don't think there is a hard-and-fast rule for compound adjectives.

I would tend to use “UTF-8 encoded” as a predicate adjective, as in “If the text is UTF-8 encoded, …”, but “UTF-8-encoded” as an ordinary adjective, as in “For UTF-8-encoded text, …”. However, in the latter case I would almost always look for a less awkward way to write the sentence, for example, “For text encoded in UTF-8, …”.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jun 5, 2018

Low priority, but we should pick one and use it consistently.

This is not true. "run time" is a noun; "run-time" is an adjective. "Run-time initialization happens at run time." (This is a rule of English, not of Go documentation.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.