At the risk of getting dinged, I have a hard time thinking this is a real article.<p>Example 1: Changing `s` to `displayScore` doesn't fix the problem the code is using `p1`, `p2`, `p1N`, `p2N` AND defining a new `p`. WITH multiple ternaries and 3 mid-function returns.<p>Example 2: Reasonable, but now you have two functions with similar signatures. Reducing the number of indentation is always good.<p>Example 3: Creates ANOTHER layer of indentation. Without add'l context the code looks like it could be reduced to a series of inverted conditions with happy/golden-path style sequential if-s instead of 5 indentation deep.<p>Example 4: Pet peeve and chided by a lot of linters. Empty blocks are generally frowned upon. (You say: "If not equals DO" not "If equals don't do anything ELSE")<p>Example 5: Good in the context of testing, annoying in that it is a function with a single line. You'd probably be better off stubbing the User class all together. I mean you're already providing a User-type object.<p>Example 6: Great, 10/10 love it. Would remove the {} and just toss the Throws on the if-statement line itself but that's personal taste.<p>Example 7: Not awful, but I like to front-load my variable declarations so you can get error-handling out of the way at the start of the function then use those variables to do the computation later. More up front about saying: "Here are the items I will use later in this function"<p>Example 8: Probably not a simple refactor. If you aren't going to update all the locations in which an "Amount"/"Currency", you're creating an artisanal class for a single use.<p>Why am I code reviewing this article? Shoo.
I've never seen tip #4 (Rewrite negative conditions) or anything like it before. I can't see how that improves readability at all. If I saw it in a code review I'd ask the developer if they forgot to fill in the body of the if statement.