Straightforward for some readers, or more straightforward for the CPU/GPU?
var listOfGoodFoos = new List<Foo>(); // is listOfGoodFoos a good name?
for(var i = 0; i< listOfAllFoos.Count; i++) // is the loop condition correct?
{
if(listOfAllFoos[i].IsGood) -- the only interesting line is burried in here
listOfGoodFoos.Add(listOfAllFoos[i]); -- is i the right index variable? (vs. j, k, n, especially in nested loops)
}
return listOfGoodFoos;
The second example is obviously correct, and highlights the condition.A quote from Tony Hoare comes to mind:
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.
And that complexity is only written once, instead of multiple times for a single project
You can have as many FOR and IF branches that you want, but only if they are all bugless!
I'd much rather see a few lambdas in a chain of function calls than blocks of conditionals and loops. Every keyword or bit of code that has to be typed is a potential source of errors, and abstractions of this sort help minimize that.
The idea that writing more than 5 letters, or a for loop here and there, is this giant cesspool source of errors is totally alien to me. Of all the ways in which my programming sucks, this was never among them. So thanks for you permission, I'll use it wisely :P
From another perspective your argument can be applied to any function call in library code.
In either case I don't think your position is that strong.
Sure, and from another perspective even the most efficient code does nothing to stop the heat death of the universe and is therefore functionally equivalent to doing anything else or nothing at all. However, that's just splitting hairs. It's not really an argument anyway, but rather a preference.