manpreet Best Answer 2 years ago

 labnol.org ranking is good and content gives you some tech dose in a more influential way.

manpreet 2 years ago

As a software engineer or programmer, what's the dumbest line of code you've seen in a codebase">codebase?

manpreet 2 years ago

Hello Karlie, 

It's not actually a line of code, so to speak, but lines of code.

I work in Salesforce, and for those who are not familiar with its cloud architecture, a component from QA could be moved to production only if the overall test coverage of the production is 75% or more. Meaning, if the total number of lines of code across all components, including the newly introduced ones, is 10000, enough test classes must be written with appropriate test scenarios so as to cover at least 7500 lines of the lump. This rule is enforced by Salesforce itself, so there's no going around it. Asserts, on the other hand, could be done without.

If the movement of your components causes a shift in balance in production and tips its overall coverage to below 75%, you are supposed to work on the new components and raise their coverage before deployment. A nightmare of sorts, because there is a good chance your code is all clean and the issue occurs only because of a history of dirty code that had already gone in over years to drag the overall coverage to its teetering edges.

Someone in my previous company found out a sneaky way to smuggle in some code of his (or hers) without having to worry about this problem.

So this is simple math, right? If you have got 5000 lines of code, 3750 must be covered. But what if I have managed to cover only 2500 (50%) and my deadline is dangerously close?

Simple. I add 5000 lines of unnecessary code that I can surely cover by just one function call, so that the overall line number now is 10000 and covered lines are 7500, making my coverage percentage a sweet 75.

For this purpose they introduced a few full classes with a lone method in each of them. The method starts with,

Integer i = 0;

and continues with a repetition of the following line thousands of times.

i++;

And they had the audacity to copy and paste this repetitive 'code' throughout a bulky method and across classes in such a reckless manner that you could see a misplaced tab in first line replicated exactly in every 100th line or so.

Now all that is left for you to do is call this method in a test class, and you can cover scores of lines without breaking a sweat. All the code that actually matters may lie untested in automated coverage check, glaring red if one should care to take a look at, but you have effectively hoodwinked Salesforce deployment mechanism.

And the aftermath is even crazier. Seeing the way hoards of components could be moved in without having to embark on the tedious process of writing test classes, this technique acquired a status equivalent to 'Salesforce best practices' in our practice. In almost all the main orgs, if you search for it, you can find a class with streams of 'i++;' flowing along the screen for as far as you have the patience to scroll down.

Well, these cloaked dastards remained undetected for years before some of the untested scenarios started reeking. More sensible developers fished out the 'i++;' classes, raised the alarm and got down to clean up the mess. Just removing those classes drove the overall production coverage to abysmal low, preventing any form of interaction with production. What can I say, that kept many of us busy for at least a month.

I wouldn't call the 'developers' that put this code in dumb. I would rather go for 'wicked'. The higher heads and testers who didn't care to look while this passed under their noses do qualify as dumb.

And the code... Man, that's the dumbest thing I've ever seen.