Oof, these all seem absurd to me. > 1. Only One Level Of Indentation Per Method One level of indentation just leads to an explosion of tiny one-use methods wi

Oof, these all seem absurd to me. > 1. Only One Level Of Indentation Per Method One level of indentation just leads to an explosion of tiny one-use methods with weird names, and now you can't read the code linearly. You will almost certainly never reuse these tiny methods, especially since you're likely consigning them to an instance of a class instead of a free function, so all you've done is forced people to jump around a lot. > 2. Don’t Use The ELSE Keyword Not using the else statement just obscures the fact that there's a branch in the code. Obscuring something important seems to be the opposite of what you should do. > 3. Wrap All Primitives And Strings Ugh, that seems verbose and clunky, especially in a language like Java without operator overloading. I'm all for type aliases or typedef's, or, creating a class if the builtin primitives don't work (I think a Money class makes sense because you don't exactly want to use a float, for instance). But just putting wrappers all over the place sounds grotesque. > 4. First Class Collections: Any class that contains a collection should contain no other member variables Why even have a class then? Why not just have functions that operate on a collection? It's much more generic that way, since if you're using iterators or an abstract collection interface, you can potentially allow the user to choose the exact data structure, and you avoid the ceremony of creating a new type that's again just a wrapper. > 5. One Dot Per Line... Basically, the rule says that you should not chain method calls. This is the first one I roughly agree with, but I wouldn't consider it a hard rule. Chaining .map and .filter together for instance is a very common pattern. > 6. Don’t Abbreviate min/max is just as clear as minimum and maximum. I'm not using "index" in my for loop when "i" will do. "n" is perfectly well understood as a count of things. Abbreviations when used properly make code easier to read, not harder. > 7. Keep All Entities Small... No class over 50 lines and no package over 10 files Ok, assuming the problem can't be simplified, all you've done is now fractured all that functionality into tens/hundreds of files. How is that easier to follow? Sure, there's balance in all things, but I'd probably rather read a 1000 line class than 20 small files split over 2 packages. > 8. No Classes With More Than Two Instance Variables... I thought people would yell at me while introducing this rule, but it didn’t happen They were being polite. I'll do it for them. What the fuck? The example he gives is also awful, where instead of using a string for name, he makes Name a type (ugh) with FirstName and LastName. Not only is that overly ceremonial, but it's wrong, there are plenty of names from various cultures that do not fit cleanly into FirstName and LastName. Also, what happens if he wants to store a MiddleName? That's three instance variables! Ohno! OR what if the person has like 10 middle names (this shit happens). Are we going to have 5 nested data types for that? > 9. No Getters/Setters/Properties ... My favorite rule. It could be rephrased as Tell, don’t ask. My brain feels like it's going to explode. > It is okay to use accessors to get the state of an object, as long as you don’t use the result to make decisions outside the object. Why else would you want to get the state of an object? > Any decisions based entirely upon the state of one object should be made inside the object itself. If your classes are 50 lines long, I guarantee you that other classes will be making decisions on other objects behalf. > Then again, they violate the Open/Closed Principle. I think the industry is largely realizing that this is a bad principle, as it implies inheritance. I think most people outside the enterprise java world now realize that using interfaces or free functions is largely better.