Writing Rules to Disregard | Hacker News Reader

Writing Rules to Disregard

theparisreview.org

33 pointsdaddy_drank13 comments

The (funny) classic reference being:

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

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

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.

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

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

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.

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.

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

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.

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.

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.

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...

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.)

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

Reply on news.ycombinator.com