Only for trivial code or if you're doing time-intensive line-by-line debugging - and when writing trivial code, nothing matters because none of the problems of bad programming show up. The reason we do things a certain way is to avoid problems when the code becomes long and convoluted (incidentally - the raison d'etre for OOP).
Again, i disagree. In trivial code, your belief holds truer but is still usually false. As code becomes more complicated there is more and more to follow. I am well aware why it is claimed to be the way to do things, but more often then not, it just complicates it.
EDIT: yeah, as Abuse points out, with your trivial example the problems of your approach don't really show up yet.
Looking at your code below, your fix succeeded in complicating it, re-stepped the logic and made it slower all at the same time
Again, I often see the reverse. Speaking striclty from experience here.
I am speaking strickly from experience as well. Perhaps we just have different experiences.
The point is precisely that it is NEVER instantly clear to have your return anywhere but at the end of the method.
But it is clearer. The only thing having a return at the end of the method tells you is : "If I follow this code through all paths I will end up here some how". Where as having a return earlier means "I have followed the code and now the remainder does not apply to this condition". When debuging code, that piece of knowledge can save you time. It also tells you that if you don't think the path is truly complete, then this is a potential bug. If a variable was assigned, then you would have to follow it down to the return at the bottom to check for other assignments.
And in the majority of cases at some point in the future someone will have to modify that source and add "other operations" anyway. I speak from long experience. Again, this is part of why we bother with the additional effort and inconvenience of OOP: not to save time NOW but to save it LATER.
I too speak from experience.
Sure, if you thought it was a simplification of raw source then I would agree it's a bad one. Rather, it's a simplification of maintenance effort.
We see things the opposite way, while both trying to reach the same goal
public int compareStrings(String s1, String s2) {
int len1 = s1.length();
int len2 = s2.length();
int max = Math.min(len1, len2) + 1;
// Set default value if no match found
int result = len1 - len2; // HERE
char a1[] = s1.toCharArray();
char a2[] = s2.toCharArray();
for (int i=0; i < max; i++) {
char c1 = a1;
char c2 = a2;
if (c1 != c2)
{
result = c1 - c2; // HERE
break; //HERE
}
}
return result;
}
Oh, really? You're sure about that?
Absolutley. You just proved it.
// Set default value if no match found
int result = len1 - len2; // HERE
You just handled the exception condition first. Logic would indicate a default value should fulfill the most common condition, not the exception. Also, because it is the exception, it is wasteful to determine it at this time and therefore less efficient. When debugging, this code has added complexity because you later modify the value. "int result" may NOT be the real
result. The maintainer will have to follow it all the way through now to see if it will be modified somwhere else (and it may be in this case). As the complexity and size of the method grows, this will get harder and harder to do. There is no value added by that change. It is more complicated, less efficient and harder to debug.
The coding style you propose is responsible for costing or saving thousands of dollars on individual projects even with only a few programmers. In general, bad coding style can burn as much as 30% of the total project cost. Go figure.
I agree about bad coding style, but I don't see this as an example of that. If it keeps the logic clearer and makes the code simpler to read, and it's more efficient, then I find little problem with it, despite the "rule of thumb". I have dozens of programmers working for me and I wouldn't fault any of them for doing a return in a loop, unless it was a case where it made things less clear, and those IME are the exception.
