marklio - Silly Code

Tuesday, September 12, 2006

For some reason, it really bothers me when I see this pattern in code (using no particular language):


someVar = false;

if (someCondition) {

   someVar = true;

}

This can, of course, simply be specified as:


someVar = someCondition;

Now, I understand that as code is refactored, this pattern can appear due to simplifications...but still...come on. It's even worse when someVar is used only as the condition of another if block.

UPDATE: This seems to occur most often in code whose ownership has changed hands several times. New owners seem to fall into either trying to edit the code while maintaining the structure as closely as possible, or by heavily refactoring. Many times, the former choice is made, especially if the original owner is still around somewhere. Usually my first instinct when I inherit code is to massively refactor. I'll post a more in-depth view on this later.

Technical

posted on Tuesday, September 12, 2006 2:09:58 PM (Pacific Standard Time, UTC-08:00)

Tuesday, September 12, 2006 4:12:34 PM (Pacific Standard Time, UTC-08:00)

That is a good one. I also prefer

def foo(x):
  return x == 3

in favor of

def lamefoo(x):
  if x == 3:
    return True
  else:
    return False

Casey | casey dot marshallAT NOSPAMgmail dot com

Tuesday, September 12, 2006 4:13:54 PM (Pacific Standard Time, UTC-08:00)

Doh! Never can win with trying to make blog comments indent Python code correctly! :(

Casey | casey dot marshallAT NOSPAMgmail dot com

Tuesday, September 12, 2006 4:24:51 PM (Pacific Standard Time, UTC-08:00)

Ha ha. Yeah, it's like a box of chocolates.

Mark

Wednesday, September 13, 2006 6:08:13 AM (Pacific Standard Time, UTC-08:00)

True, but if your condition is 10 million characters long, the tradeoff between concise code is code readability/maintainability.

I like abbreviated code, but having to sit there and interpret and debug one line pops makes me cringe...

Dan Obregon | mcrib96AT NOSPAMgmail dot com

Wednesday, September 13, 2006 7:32:11 AM (Pacific Standard Time, UTC-08:00)

It occurs to me that the the 10 million character condition may be the thing that needs some work. It also occurs to me that with 10 million characters, the handful of characters needed for the if statement aren't going to make it that much less readable/maintainable. Seriously though, there is almost always a tradeoff between conciseness and maintainability. I recall a post by someone naming off the deadly sins of coding, and one of them was being clever for cleverness's sake. In my opinion, in this case the extra variable provides an extra level of indirection which make the code less readable. The case of the complex condition should be solved by breaking the condition up through functions, or extra composition steps. Sure, there will be exceptions to the rule, such as when conditional steps must be interleaved with unconditional steps. But, in general, the primary conditions should be discoverable at the point of decision.

Mark

Saturday, September 16, 2006 5:56:58 PM (Pacific Standard Time, UTC-08:00)

Well, I wouldn't like maintaining any of Casey's code. I am not familiar with Python, but in Perl and other languages, there is a difference between what the statement "x == 3" returns and what "return True" actually returns. Usually, the differences are suttle, but can lead to some very weird bugs that take lots of time to run down. I have experienced this pain, and now I *always* code the long if statement. In my old age, I harldy ever write "concise" code. Readability/maintainability always wins out. Maybe because my old fart of a brain can't hold as much as it used to. I would rather have the code read easy, than cause me to scratch my had and step through it several times figuring out what it does. Maintence is the largest part of the software life cycle. Spend the time upfront, when it doesn't cost you much, and you save mucho time over the life of the product. But that is the way things are most in life right? To me, it is the same philosophy as saving for retirement and compound interest. Do a little extra up front, which saves you a lot of extra in the future. But then, I also consider myself an old fart so YMMV with my coding philosophy. :-)