A question:
What does the following code do?public static string GetThing1(string s)
{
return s.Substring(s.Length / 2 - (1 - s.Length % 2), 2 - s.Length % 2);
}
Given that code, take a look at the following, what doe this code do?
public static string GetThing2(string s)
{
//Given a string return the middle char if odd, middle 2 if even
string retVal = "";
bool even = (s.Length % 2 == 0) ? true : false;
int middle = (s.Length % 2 == 0) ? s.Length / 2 - 1 : s.Length / 2;
if (even)
retVal = s.Substring(middle, 2);
else
retVal = s[middle].ToString();
return retVal;
}
It probably didn't take too long to figure out they both do the same thing. They are two different answers to the following question:
Write a function to get the middle character of a string. Return the middle character if it the length is odd, or the middle 2 characters if the length is even.Which version took less time to understand? Personally, I found the second version easier to understand. I also figure it will be easier to debug.
And so?
I happened across these two solutions at CodeWars.com. The first answer was voted a best practice.
Isn't maintainability a best practice? Isn't clarity a tool for enhancing maintainability? I think that under the assumption that the code I write will be looked at later by someone who has no idea what the code needs to do, I need to leave as many markers as possible. I need to be explicit in my coding. This might be an extreme example. The second version could be re-written to be more concise - especially to try and get rid of some of the extra memory used.
But what about making the fact that the return is value is a "this" or "that" known explicitly? The intent is obscured in the one-liner. This becomes a more interesting trade-off - will this routine be called frequently? How much are we paying in performance for the conditional? Does it need to be streamlined? How do you keep maintainability and meet that goal?
As Abelson and Sussman phrase it in “Structure and Interpretation of Computer Programs,” “Programs must be written for people to read, and only incidentally for machines to execute.”
(quote from Code Watch: Let's be clear about code clarity)
Isn't maintainability a best practice? Isn't clarity a tool for enhancing maintainability? I think that under the assumption that the code I write will be looked at later by someone who has no idea what the code needs to do, I need to leave as many markers as possible. I need to be explicit in my coding. This might be an extreme example. The second version could be re-written to be more concise - especially to try and get rid of some of the extra memory used.
But what about making the fact that the return is value is a "this" or "that" known explicitly? The intent is obscured in the one-liner. This becomes a more interesting trade-off - will this routine be called frequently? How much are we paying in performance for the conditional? Does it need to be streamlined? How do you keep maintainability and meet that goal?
As Abelson and Sussman phrase it in “Structure and Interpretation of Computer Programs,” “Programs must be written for people to read, and only incidentally for machines to execute.”
(quote from Code Watch: Let's be clear about code clarity)
These are the questions I am asking myself about this code - what about you?
Comments