> encourage one-liners Less merge friendly as well. Also you should only do one thing per line when it comes down to it to increase simplicity. I like compact

> encourage one-liners Less merge friendly as well. Also you should only do one thing per line when it comes down to it to increase simplicity. I like compact code but not adding complexity for no reason so others on the team can be confused. > Comments are rarely extra weight if there's anything worth explaining Good cases are non obvious flows and especially algorithms/notes or any section that will be public or generate docs from it. But mostly comments are weight not because they aren't good, but because they aren't updated and become out of date weight. > Collection types are no replacement for OO patterns that have a reason to exist in the first place. They definitely have a place but prototyping even they are better. They are the base of json/xml data formats and most languages. Everything on top of that should have a reason for complexity including OO as long as it improves understanding and simplicity. The "simple but not too simple" rule is what a programmer/engineer should live by. > good argument to be made that early exits, other than perhaps constraint checking, make control flow harder to reason about I'll fight to the death for better flow with early exits it is much easier flow with less indentation. There are times where you do need to go about it differently but most do not.