Why Clean Code Seriously Matters!

The first example is some working code, that determines if a date value is a weekend day and returns true or false based on that.

[sourcecode language=”csharp”]
bool firstSecondNulls = false;
var dayOfWeek = (DateTime) zeros.ElementAtOrDefault(i).BalanceDate;
if (dayOfWeek.DayOfWeek == DayOfWeek.Sunday || dayOfWeek.DayOfWeek == DayOfWeek.Saturday)
firstSecondNulls = true;
return firstSecondNulls;
[/sourcecode]

This second example also provides the same result, except in a more readable, cleaner, and more efficient way. Matter of fact, I’d say in some circumstances it is exponentially more efficient! Do you see why?

[sourcecode language=”csharp”]
var dayOfWeek = (DateTime) zeros.ElementAtOrDefault(i).BalanceDate;
return dayOfWeek.DayOfWeek == DayOfWeek.Sunday || dayOfWeek.DayOfWeek == DayOfWeek.Saturday;
[/sourcecode]

This is an insanely simple example. But just imagine some of the nightmarish methods and functions, with hundreds of lines of code. Keep in mind, that those nightmares are minimal compared to the Enterprise Scale 1000+ plus line methods! Yes, those exist and they are beyond nightmares but holocausts of thought and design!

So the next time you think “meh, I’ll refactor it later.” just take that extra minute or two and do it now! The pay off, you know full well when you think about it, is massive in the end. Cheers!

Published by Adron

See: http://compositecode.blog/about

8 thoughts on “Why Clean Code Seriously Matters!”

  1. Pingback: Developer Forums » Why Clean Code Seriously Matters! » Developer Forums

  2. You’re either an asset or a liability to the business. “Just doing your job” will make you more of the latter than the former.
    Devs have alot of indirect power over the business and therefore need to act accordingly responsible. You mess up big, and the business suffers the consequences.
    You create a mess, and the business must use previous

  3. You’d think people would act responsibly and not create expensive messes. Sadly there are many who are just doing their job and not taking pride in their work

  4. Ok, I give up. How could the second example be “exponentially more efficient”?

    In either case, it seems that the limiting factor would be ElementAtOrDefault(), which is either O(n) in the length of zeros, or just constant time if it’s an IList. Everything else is constant time. It is notoriously difficult to produce code that runs exponentially faster than constant time. 🙂

    You only touch zeros once, so you don’t run the risk of iterating an IEnumerable multiple times.

    You call the same methods in both examples, in the same order, so there’s no reduced risk of, say, avoiding a JIT compile.

    Worse, it seems quite possible that the compiler would inline the assignments of the first example, producing IL that’s more or less equivalent to the second example. I could certainly be missing something, but I’m not convinced that the second example would even be *any* faster, much less “exponentially” so.

    What’d I miss?

    1. In the first bit of code, the code loops thru and can be assigned to “True” multiple times. Even if it is already set to “True”. In the second bit of code once it is set to “True” it immediately returns that it is true. Depending on how many data entities it has to loop thru, the first bit of code has to execute a whole lot more to get the same result.

      In the first bit of code there is also the assignment of a variable that is set to false, that is returned at some point as either “False” or “True”. There is no need for this variable. I’m betting the compiler gets rid of it in the final compiled code, but in code the variable adds no significant increase in readability nor does it even need to exist.

      Another refactor that would also probably reduce overhead in this method is if the date was just passed in instead of being cast and assigned from the “(DateTime) zeros.ElementAtOrDefault(i).BalanceDate” property.

      Cheers! 🙂

      1. Um, each of those samples immediately returns from the first invocation. Where is this “loop” you mention? Who is looping through data entities?

        I’m wondering if this was accidentally clipped out of a for-loop that increments i. We don’t seem to be looking at the same code.

        Cheers,
        Mark

  5. Mark Knell – You’re correct, I goofed. The assumption is that each of these were in a loop. I ended up posting newer code and completely forgot, but answered your question based on the old code…

    …which now that I look at it I realize I must have pasted the wrong bits into the code when putting this together in the first place.

    Glad you pointed it out… if I can find the code I’ll paste the original code that was intended for this blog entry… otherwise I might actually delete this blog entry as the code is truly out of sync with the text/conversation. 🙁

    Albeit the second is cleaner & more efficient (albeit in a negligible way) than the first example.

Comments are closed.