Writing Rules to Disregard(theparisreview.org)

33 pointsby daddy_drank7 anni fa13 comments

https://www.theparisreview.org/blog/2019/02/01/three-writing-rules-to-disregard/

5 comments

jaclaz7 anni fa

The (funny) classic reference being:

https://news.ycombinator.com/item?id=16422686

https://news.ycombinator.com/item?id=16429640

war10257 anni fa

I've rarely seen those three rules followed by anyone in normal writing.

Usually when I see someone strictly adhering to those rules (particularly not ending a sentence with a preposition), it sets of a warning flag that the writer is trying too hard to follow imaginary rules, and maybe isn't someone whose opinion I want to take much stock in.

geoelectric7 anni fa

Wonder what the equivalent "Coding Rules to Disregard" might be.

sametmax7 anni fa

I really hate the "don't comment, good code is self explicit rule" personnaly. It's self explicit for the person who wrote it 10 years ago and had the spec and the client at hand, surely.

perigrin7 anni fa

If it was hard to write, it should be hard to understand. /s

marcosdumay7 anni fa

If you know of any coding rule that is universally true, I'd like to hear.

Maybe... Don't use goto to jump to the middle of a different block of code? I don't know any exception to this one, but it's also prohibited on all modern languages, so I don't think it's a "coding rule" anymore.

SamReidHughes7 anni fa

Oftentimes if you have some hairy code, the best option is to use a goto, make a commit or leave a note, and then clean it up later, in a separate commit. It's more bisectable and leaves a more readable diff. I'm pretty sure I've had occasion to jump into the middle of a loop as the point of entry. Duff's device is a case of this.

ghtrytttttnsa7 anni fa

mcguire7 anni fa

Single point of return from a function? No more than X lines of code in a function? Object oriented programming?

[deleted]7 anni fa

Klathmon7 anni fa

I'd say all the rules about code complexity are like this.

Recommended function/class/file size, when to abstract vs when to copy, even size/names of function arguments.

There are "rules" about all of these, but the best codebases have tons and tons of violations. Not because they are bad, but because the devs working on it know when to break those rules, and know that they are mostly guidelines.

hathawsh7 anni fa

The coding equivalent would be overzealous linter rules. For example, sometimes linters demand that all variable and function names follow a project-specific capitalization convention, but I find that type of consistency is often counterproductive.

yesenadam7 anni fa

My favourite wikipedia rule: Ignore all rules.

"If a rule prevents you from improving or maintaining Wikipedia, ignore it."

https://en.wikipedia.org/wiki/Wikipedia:Ignore_all_rules

Some explanation of what it's meant to mean, with a selection of quotes about breaking rules:

https://en.wikipedia.org/wiki/Wikipedia:What_%22Ignore_all_r...

I really like that page - so well-written. "Use common sense. ...There is no common sense." In fact, the wikipedia pages about rules are much better written and more enjoyable to read than the average article is - which seems odd, but I guess is how it should be. There are a lot of very funny pages about the rules.[0] Many essays, on every aspect of wikipedia, here:

https://en.wikipedia.org/wiki/Wikipedia:Essay_directory

(A lot of the titles and short explanations on that page are fascinating/funny, a great intro to wikipedia culture...as it should be.)

[0] e.g. https://en.wikipedia.org/wiki/Wikipedia:Essay_directory#Humo...

dctoedt7 anni fa

This is an example of how the HN rule about stripping out the "Three" in the title has resulted in ambiguity: I thought the term "writing rules" was present-participle verb + object, but it turned out to be gerund-as-adjective + noun. (I might have the grammatical labels wrong.)

yesenadam7 anni fa

True - you were hoping for advice in the construction of rules that everyone would ignore. (A bit masochistic.)