> inconsistent enforcement of its policies (which can be pretty blatant around WP:CIVIL

One of the most interesting phenomena I've come across is the way that the Assume Good Faith guideline is abused. In all the instances where I've seen it cited in a dispute, it's always a situation that goes like this:

A and B are at odds.

A is on the wrong side.

A begins to trot out a list of guidelines and policies that B has purportedly run afoul of.

Wanting to pad the list of infractions, A cites WP:AGF with really shaky rationale.

Let's examine this. The Assume Good Faith rule is basically the same in spirit as the rule here on HN that says to be charitable and respond to the strongest reading of a given comment, not the weakest one. In other words, for a given remark/comment from a person, go with the interpretation that is most favorable to the other person. By accusing B of violating AGF, A is doing the very opposite what AGF prescribes, and doing so in a really perverse way.

The post is a lot more about Java-the-language and has very little to do with the JVM.

What can it do? The only thing that prevents that is the programmer knowing what kinds of inputs they're dealing with and making sure unsafe input is properly escaped into safe input when the context calls for escaped input. There's no getting around this.

The author of the piece here has something to say about that, too: write code top-down.

> There are two ways to architect a program and write code: top-down and bottom-up.¶ […] The correct way to architect and write a program is top-down. This is not a matter of taste or preference. Bottom-up design is fundamentally busted and you shouldn’t use it. Every system I’ve been involved in that used top-down succeeded and those that used bottom-up failed. [...]

> At every level there’s pressure to do bottom-up programming. Avoid it. Instead, start at the top, with `main()` or its equivalent, and write it as if you had all the parts already written. Get that to look right. Stub out or hard-code the parts until you can get it to compile and run. Then slowly move your way down, keeping everything as brutally simple as you can. Don’t write a line of code that isn’t solving a problem you have *right now*. Then you may have a chance of succeeding in writing a large, working, long-lived program.

<https://www.teamten.com/lawrence/programming/write-code-top-...>

See also: Java for Everything <https://www.teamten.com/lawrence/writings/java-for-everythin...>