Advertisements

Don’t Write Confusing Code


Here is a very important lesson that I’ve just begun to learn:

Don’t write confusing code.

Make sure you know exactly what you plan to do. Think it out, make a solid plan, and organize it mentally. As Wil Shipley of Pimp My Code (See my Links page) says, you have to know exactly what you’re going to do, before you do it. To paraphrase, your new project is a clean slate. Every line of code is a filthy black streak. I guess every line of ugly code is a scratch…?

As I work on an app for a friend, I realized that I haven’t planned enough. As a result, a lot of my code is very convoluted, to the point where I can’t figure out the logic behind it at all. There’s too much for me to want to re-write—it’s just a huge mess that it ends up being. Had I known what I wanted every piece of code to do, I wouldn’t be in this mess.

So how would I recommend doing this? Simple—plan out all the steps as if you were manually doing them. Then, convert to code. To paraphrase Mr. Shipley again, instead of writing if (something is true) then (doing this, something, and that), write if (something is not true)…apparently it is more natural that way. I’ll let him explain:

Don’t indent and indent and indent for the main flow of the method. This is huge. Most people learn the exact opposite way from what’s really proper — they test for a correct condition, and if it’s true, they continue with the real code inside the ‘if’.

What you should really do is write ‘if’ statements that check for improper conditions, and if you find them, bail. This cleans your code immensely, in two important ways: (a) the main, normal execution path is all at the top level, so if the programmer is just trying to get a feel for the routine, all she needs to read is the top level statements, instead of trying to trace through indention levels figuring out what the “normal” case is, and (b) it puts the ‘bail’ code right next to the correctness check, which is good because the ‘bail’ code is usually very short and belongs with the correctness check.

When you plan out a method in your head, you’re thinking, ‘I should do blank, and if blank fails I bail, but if not I go on to do foo, and if foo fails I should bail, but if not i should do bar, and if that fails I should bail, otherwise I succeed,’ but the way most people write it is, ‘I should do blank, and if that’s good I should do foo, and if that’s good I should do do bar, but if blank was bad I should bail, and if foo was bad I should bail, and if bar was bad I should bail, otherwise I succeed.’ You’ve spread your thinking out: why are we mentioning blank again after we went on to foo and bar? We’re SO DONE with blank. It’s SO two statements ago.

Thank you, Mr. Shipley. Don’t write confusing code.

Edit: Etresoft below has made an important point. I also think I didn’t quite make myself perfectly clear. As I’ve said about my project for my friend, I jumped in, without proper planning. That, coupled with poor logic, is resulting in a mess that I’m fighting to pull myself out of right now. I believe that any app needs a good dose of UI design and even class diagrams—plus a good amount of reasonable logic. Don’t make code more convoluted than it needs to be.

Also, I tend to re-write a lot of code in if-else statements…that’s just more room for error, and makes code harder to manage. It was easier to do that the first time around, rather than figuring out exactly what I needed to put in the if-else.

Don’t take the easy way out, and trade that off for convoluted code.

With more experience, I may end up doing a reprise of this post. Etresoft’s right—I do learn through mistakes.

Thanks!

Advertisements
Leave a comment

1 Comment

  1. Etresoft

     /  August 29, 2010

    Shipley knows stuff, but don’t sell yourself short. You learn by doing, specifically by doing it poorly. A cobbled-together mess that is for sale in the App store is better than any code still sitting on your machine.

    Before Shipley there was Fred Brooks’ The Mythical Man-Month. One of his famous quotes is “build one to throw away.” In many cases, you don’t know what the correct solution is until you build a couple of incorrect ones.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Advertisements
  • Welcome

    My goal is to make CupsOfCocoa into a beautiful source for beginners to the iPhone platform to get started. Subscribe below for more, and stay tuned!

  • Contact Me

    If you need to contact me for any reason, feel free to send me an email.
  • The Giving Spirit

    If you've found this site helpful, would you consider donating a little sum? Any amount is appreciated...Thanks so much!

  • Roadmap

  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 222 other followers

  • Back to the Past

    August 2010
    S M T W T F S
        Sep »
    1234567
    891011121314
    15161718192021
    22232425262728
    293031  
  • Time Machine

  • You count!

    • 621,662 views
  • Worldwide Stats

    free counters
  • Advertisements
%d bloggers like this: