Some comments on this article: first of all it's not about the amount of lines of code that attribute to the complexity of the code, but the amount of things t

Some comments on this article: first of all it's not about the amount of lines of code that attribute to the complexity of the code, but the amount of things that actually happen and can fail in your code that can make it fragile. A godegolfed line of code is not more reliable than everything neatly expanded and tabbed in lines. Frequently in C# LINQ-queries turn out to be very long indiscernible chains of things happening that aren't completely obvious in what they're doing. Same goes for filter / map / forEach. I use them a lot but I put them often in several variables ('let' in this case of course) just to have the "one thing happening in one line" kind of code that's so much nicer to the eyes. I never benchmarked it, but I never had to. I assume modern compilers that see a constant that is only being used once understand that it comes down to the same as chaining directly. The best takeaway from this story is that filter / map / etcetera better show the intent of the code. That's why I love the `guard` statement so much. It doesn't do anything I couldn't do before but it simply tells the other programmer "unless this passes nothing else below this should happen".