I was debating on bitwise operations, but decided on super basic if statements which I think the compiler would optimize, happy to see the logical operation form too
I should have created a local variable to store the result variable and return after the if statements. I just couldn’t help to make it look partially nice. My brain just doesn’t think at this high caliber of LOC optimizations.
New optimized LOC version:
internal staticboolAreBooleansEqual(bool orig, bool val)
{
boolresult;
if(orig)
{
if(val)
{
result = false;
}
else
{
result = true;
}
}
else
{
if(val)
{
result = true;
}
else
{
result = false;
}
}
returnresult;
}
Surely we could optimize the return value with a switch statement and store the result as an integer to hide the compiler warning about our clearly correct code:
Make the input variables nullable, then add checks if the values are null, then assign default values if they are, otherwise continue with the passed values.
Good idea but not feasible as that could introduce unknowns. Unfortunately making defaults when null is counterproductive as we are looking to increase LOC without introducing odd behavior and having no changes to how the overall function works. The only objective is to increase LOC.
Those are rookie lines of code numbers right there.
I would have done it without the
==internal static bool AreBooleansEqual(bool orig, bool val) { if(orig) { if(val) return false return true } if(val) return true return false }Don’t know why their code returns false when they are equal but I’m not going to dig through old code to refactor to use true instead of false.
you can also use XOR operation
return (X || Y) && !(X && Y)I was debating on bitwise operations, but decided on super basic if statements which I think the compiler would optimize, happy to see the logical operation form too
Put more curly brackets around your if (val) true statement for 4 more lines, put elses in there for more lines even.
I should have created a local variable to store the result variable and return after the if statements. I just couldn’t help to make it look partially nice. My brain just doesn’t think at this high caliber of LOC optimizations.
New optimized LOC version:
internal static bool AreBooleansEqual(bool orig, bool val) { bool result; if(orig) { if(val) { result = false; } else { result = true; } } else { if(val) { result = true; } else { result = false; } } return result; }My previous LOC: 12
New LOC version: 27
Surely we could optimize the return value with a switch statement and store the result as an integer to hide the compiler warning about our clearly correct code:
internal static bool AreBooleansEqual(bool orig, bool val) { int result; if(orig) { if(val) { result = 0; } else { result = 1; } } else { if(val) { result = 1; } else { result = 0; } } switch (result) { case(1): return true; case(0): return false; default: return AreBooleansEqual(orig, val); } }New LOC: 35
Make the input variables nullable, then add checks if the values are null, then assign default values if they are, otherwise continue with the passed values.
Good idea but not feasible as that could introduce unknowns. Unfortunately making defaults when null is counterproductive as we are looking to increase LOC without introducing odd behavior and having no changes to how the overall function works. The only objective is to increase LOC.