At what point does LINQ become too terse and procedural techniques resorted to?
A:
When you can no longer do what is required to be done (easily).
Matthew Scharley
2009-06-28 13:08:01
+3
A:
Terseness is in the eye of the beholder. When you're not comfortable with the code anymore, then it's time to refactor it a bit. The refactoring could be swapping to some procedural bits, or breaking your linq queries apart, or whatever it takes to make it understandable again. As long as the intent of the code is obvious, it shouldn't matter how terse it is or what techniques are used to achieve the end goal :-)
Dan F
2009-06-28 13:15:18
I'd even go so far as to say that terse but clear (as to intent) code is a very good idea.
Matthew Scharley
2009-06-28 13:24:16
LINQ is certainly dense, but I kind of like it that way. I hate it when there's so much junk and extra whitespace that you can't get a feel for what the big picture is. LINQ query + comment (if necessary) is very easy to grok quickly. Long procedures often need a bit of mental agility required - sure you can understand what's happening on any given line, but patching it all together in your head to figure out what it's actually *doing* can be a lot more time consuming.
Iain Galloway
2010-03-29 16:11:21
+2
A:
Any language construct, not just LINQ, is too terse when the majority of people on your group cannot quickly understand what a line of code is doing.
JaredPar
2009-06-28 15:02:49
I agree, but I also dare say that this is only part of the picture: I believe the intent of a line of code can be incomprehensible due to other reasons than terseness alone. Perhaps in cases where variable names aren't self-explanatory (e.g. because they're cryptic or misleading) and therefore one fails to grasp the full meaning of the statement around it.
stakx
2010-06-10 21:21:22