1
2

[–] RevanProdigalKnight 1 points 2 points (+3|-1) ago 

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

0
1

[–] 6gorillion 0 points 1 points (+1|-0) ago 

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
1

[–] BakedMofoBread 0 points 1 points (+1|-0) ago 

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
1

[–] SquarebobSpongebutt 0 points 1 points (+1|-0) ago 

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
0

[–] roznak [S] 0 points 0 points (+0|-0) ago 

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.

0
1

[–] SquarebobSpongebutt 0 points 1 points (+1|-0) ago 

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.