Stop using these giant single liners

1    10 Jun 2018 01:44 by u/roznak

I see it a lot, one giant Linq statement or code.

  1. That code won't run any faster
  2. That code is basically a way to hide your insecurities as a developer by creating such a complex thing no one will dare to ask you what it does.
  3. The compiler/interpreters has no clue what you as a developer even whats you to do. So it is going to take safe guesses and actually worsen performance. It is not intuitive but splitting the parts into multiple lines that actually uses variables will make the compiler/interpreter create more optimized code because it knows what you want and what you don't want.
  4. That giant one-liner, you have no clue what it will actually do. You can guess what it does because, hey I have put the names in order, but bugs in the libraries or bad naming may actually do something completely different.
  5. It is a complete disaster to even start to debug it.

7 comments

0 u/RevanProdigalKnight 10 Jun 2018 02:28

Tell that to the Java developers who make function names that are entire sentences by themselves.

0 u/SquarebobSpongebutt 10 Jun 2018 02:32

I admit I am guilty of it sometimes, mostly with LINQ or SQL. I test the statement in LINQPad or SQL Management Studio and just move it over from there, chucking in variables for values. And yes, I hate myself for it and am trying to break it.

0 u/roznak [OP] 15 Jun 2018 21:21

The danger over time I have noticed is that you lose track what that LINQ statement actually does. A bug in the code somewhere else could trigger unexpected side effects you never could have predicted. You are at the mercy of the implementation behind LINQ to do the correct thing.

The other thing I have noticed when you are searching for bugs, your brain will actually ignore that LINQ part because it is too complicated to reverse engineer. It takes a lot of mental energy to understand the code. And during stress and deadlines, your brains skips over the obvious bug in that LINQ statement.

Also over time you will get scared to modify that LINQ statement so you create parallel code that almost does the same thing but not quite the same. Code gets duplicated, adding confusion because now you have more code in your project that looks similar. Before knowing you are modifying the wrong LINQ statement.

1 u/SquarebobSpongebutt 15 Jun 2018 22:51

I also recently had one where the LINQ was so deconstructed that it was almost impossible to reconstruct to tell what it was doing. The actual statement was a string of variables that held the different parts of the statement. So I used the debugger to grab a full statement. Then I had to figure out what was wrong with the statement and find where in code that was being passed. There is such a thing as making things too many lines.

I will note that this is not 100% new problem and is off-shore coders doing it. They have done it to SQL over and over and any object they create has a good chance of actually being one object hidden behind three other layers of other objects that don't actually do anything but create a new object. Not talking about inheriting and modifying the usage of an object. I mean literally just call a new object with the passed parameters.

0 u/BakedMofoBread 10 Jun 2018 03:55

Laziness is occasionally a virtue while programming; sometimes it takes less time to write the linq statement rather than a foreach.

But then again, if it’s such a trivial app that I’d sacrifice future maintenance for completion speed, then I’m likely the only one who’s gonna ever use it.

0 u/6gorillion 10 Jun 2018 07:46

what you as a developer even whats you to do

Who knows what you even whats you to do. Has anyone ever been that far decided?

0 u/WhiteMakesRight 15 Jun 2018 20:57

90% of everything is shit. Complaining about it is yet more shit.