You see, I was working on this function that returned a value based on a few incoming parameters, and the lead admitted he was having difficulty reading the code.  It looked something like the following snippet:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

int myFunction( int a, int b, int c )
{
  /* Initialize return value */
  int returnValue = 0;
 
  /* Determine return value */
  if ( a == 0 || b == 0 || c == 0 )
  {
    /* Provided values are invalid, return -1 */
    returnValue = -1;
  }
  else
  {
    if ( a > b )
    {
      returnValue = 1;
    }
    else if ( b > c )
    {
      returnValue = 2;
    }
    else if ( c > a )
    {
      returnValue = 3;
    }
    else
    {
      returnValue = 0;
    }
 
    // Do more stuff here
 
  }
 
  /* Return the value */
  return( returnValue );
}

Lets take a minute to review this function…

• At line 1, we begin our function and accept 3 integers
• At line 4, we create a variable to hold the value our function will return upon completion
• At line 7, we enter an if statement and check to see if any of the provided values are 0
• If any of the values are 0, then we set our return value to -1
• Otherwise, we enter our else block and determine our return value
• At line 31, we have code that does other important stuff
• Finally, at line 36, we return our return value

Note: the “other stuff” code at line 31 was not reproduced as we don’t really care what it does in this example, but we do need to know that it is there.

My Lead’s beef with the function above mostly had to do with lines 7 through 33. Specifically, he deplored the fact that the if statement was the length of the function, and also questioned the reasoning behind letting the function continue its flow if the parameters were determined to be incorrect. (For example, if we add code to line 34, it will be run regardless of the parameters being valid or not.)

He explained that, although nested if statements could be useful from time to time, they should generally be avoided as they make code difficult to maintain.

So I asked him how I could avoid nested if statements, and he proposed that I simply return the -1 value at line 10, instead of assigning it to a variable and returning it later on. This would simplify the function, and would remove the function-long if statement:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

int myFunction( int a, int b, int c )
{
  /* Initialize return value */
  int returnValue = 0;
 
  /* Validate Parameters */
  if ( a == 0 || b == 0 || c == 0 )
  {
    /* Provided values are invalid, return -1 */
    return( -1 );
  }
 
  /* Determine return value */
  if ( a > b )
  {
    returnValue = 1;
  }
  else if ( b > c )
  {
    returnValue = 2;
  }
  else if ( c > a )
  {
    returnValue = 3;
  }
  else
  {
    returnValue = 0;
  }
 
  // Do more stuff here
 
  /* Return the value */
  return( returnValue );
}

And there we go. By immediately returning the value -1, we can remove the else block and avoid putting the whole function in an if statement.

This might not seem like much right now, but one day you might run into a very large function with multiple lines of code and multiple if statements that persist throughout the function. And on that day you’ll hit your forehead with your hand and wonder why the function’s author didn’t read FuglyCode.com

Function Optimization

This function could be even more optimized. Can you figure out how?

Try rewriting this function to make it as optimal as possible and then compare what you wrote with my code (click on the down arrow to expand the code box). Feel free to share your code in the comments if its any different from mine!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

int myFunction( int a, int b, int c )
{
  /* Validate Parameters */
  if ( a == 0 || b == 0 || c == 0 )
  {
    /* Provided values are invalid, return -1 */
    return( -1 );
  }
 
  /* Call new doMoreStuff function */
  doMoreStuff();
 
  /* Return a value */
  if ( a > b )
  {
    return( 1 );
  }
  else if ( b > c )
  {
    return( 2 );
  }
  else if ( c > a )
  {
    return( 3 );
  }
 
  return( 0 );
}
 
void doMoreStuff ()
{
  /* Move the do more stuff into its own function *
   * to increase reusability and readability */
}

It's So Fugly...

FuglyCode of the Week
Every Monday at 12pm eastern

Every week, take a look at software code as we study the dos and dont’s of software development.

Latest Article: Multiple Nested If Statements

Blog Tools

Blog Tools Reviews
Every Wednesday at 12pm eastern

Interested in building an online blog?  Join FuglyCode as we review useful blog plugins that you can use on your WordPress blog.

Latest Article:  Blog Widgets, Flexo Archives

So first, you’ll notice a new Welcome post on the site’s front page.  The goal of this new post is to help visitors quickly access the site’s latest content.  I expect to replace the post with a full time web page, but until that page is built, keep an eye on the post for any updates.

Also, you may have noticed no articles have been posted for a couple of days now.  Well, I’ve been having some issues with new posts that are waiting to be published.  I hope to resolve these issues soon and begin posting new articles next week.  In the meantime, keep an eye on the site in the event something I resolve the issue this week.

Lets take the following snipped of FuglyCode for example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public boolean Tester( Object myObject ) {
  String myString;
  Integer myInt;
  try
  {
    // Save the string
    myString = ( String ) myObject;
 
    // Do more String stuff...
  }
  catch ( Exception e )
  {
    // The object was not a string
    // Save the integer
    myInt = ( Integer ) myObject;
 
    // Do more Integer stuff...
  }
 
  return( true );
}

Special thanks to jpuly for submitting this code. Submit your fugly code here.

Before we begin analyzing the fuglyness of this code, lets go over it to make sure we all understand what seems to be going on:

• At line 1, we enter our Tester method and receive an object
• At line 7, we attempt to save our object to a String variable
• At line 11, we catch any exception of type Exception (pretty much, we catch any exception)
• At line 15, we assume that the exception was caused by saving the object to a string, so we save our object to an Integer variable

One of the biggest problems with this code is that, although we accept any Exception type, we assume that the only reason our code would throw an exception would be because of the String cast on line 7. What if the myObject parameter is a String, and code does something on line 9 that throws an exception?

Obviously the exception will be caught and the catch block will be run. Because myObject is a string, however, the Integer cast on line 15 will throw an exception, and since we don’t have any code to handle and exception thrown at that line, our program will crash and burn.

So what could you do? Well, you could begin by using a much more specific Exception type. In fact, changing line 11 to “catch ( ClassCastException e )” would ensure that we only enter the catch block if the String cast on line 7 failed, although it wouldn’t protect against other exceptions being thrown, or against myObject being something other than a String or an Integer.

KISS!

In this particular situation, we need to take a step back and look at the method as a whole. What are we trying to accomplish here? Does the code have to be so complicated? (Remember KISS!)

Truth is, our Tester method is using error handling to make a decision (if myObject is a String, do something, otherwise, do something else). Not only is this poor software design, but it fails to capitalize on the programming language’s built in ability to overload methods.

So, lets scrap the error handling altogether, and split this method into two similar methods with differing signatures:

1
2
3
4
5
6
7
8
9
10

public boolean Tester( String myString ) {
    // Do String stuff... (optionally wrap in try/catch block)
 
    return( true );
}
public boolean Tester( Integer myInt ) {
    // Do Integer stuff... (optionally wrap in try/catch block)
 
    return( true );
}

And there we go! Now we have two methods with the same names (meaning our calling code doesn’t have to change). We also specify our parameter types, meaning that the compiler will not allow us to call Tester with anything other than either an Integer or a String. And as a final and optional touch, we can add error handling at lines 2 and 7, in case these lines risk throwing an exception.

If you have any questions, feel free to post them in the comments section below.

If you would like to ask your question privately, you can send it using the Contact Us form.

Do you have any FuglyCode you would like to share? If so, then submit it!

What’s a widget?

A WordPress Widget is a plugin (or part of a plugin) that is designed to provide a simple way to arrange the various elements of your blog’s sidebar content without having to change any code.

- Paraphrase from WordPress.org’s Widget Page

So in other words, a widget can be seen as the physical manifestation of a plugin on your site.

If you take a look at the side of the screen you’ll see FuglyCode’s sidebar, and within that sidebar you’ll see a login form (that is, unless you’re logged in, of course), which is one of a handful of widgets displayed on the site.

Some plugins will come with one or many widgets, that you can freely add to your sidebar as you see fit, whereas others do not require a widget to work (Akismet, for example, does not need to be displayed on the sidebar for it to filter comment spam).

Large Archives

The Popular Archives Widget

One of the most popular widgets I’ve seen on blogs is the Archives widget (which should be somewhere on FuglyCode’s sidebar as well).  The widget lists each month your blog has been in operation, along with the number of posts for that month.  When the visitor clicks on the month, they are presented with a short description of each post and can read further by clicking on those posts.

This widget is very useful, as it allows visitors to jump to past posts that would otherwise be buried deep within your blog with just one click.  An issue arises, however, when your blog begins to age.  My personal site, for example, has been online for over two years, and the default Archives Widget (seen to the left) has gotten quite long.

Flexo Archives to the Rescue!

Large archives can become a nuisance to visitors, and take up a lot of valuable site retail space on your blog.  Luckily, today’s plugin offers a quick and easy solution to the problem.

Developed by heathharrelson, Flexo Archives comes with its own widget that you can use instead of the default Archives widget provided by WordPress.  The widget regroups the months of your archive into collapsible years, which visitors can then click on to expand.

Its very easy to install (honestly, it only takes 2 to 3 clicks of the mouse), although it only works if visitors have JavaScript enabled (without javascript, all months display just like the default archive plugin).  Some users have also reported that their archive list will sometimes not match the look of their blog.  This is more often than not caused by the blog’s stylesheets not having any defined styles for lists.

Flexo Archives

The Recap

Pros:

• Quick and easy install
• Removes website/blog clutter
• Easy to use

Cons:

• JavaScript must be enabled
• Stylesheets may need to be updated for bullet lists to match blog theme

You can find out more about Flexo Archives on the WordPress Plugins Directory

Its So Fugly...

Do you work with code?  Does the code you work with cause your hand to hit your forehead at least three times a day?  Is the code you work with Fugly?

If you’ve answered yes to any of these questions, then you may have FuglyCode!

Alright, big news on the FuglyCode front, we’re looking to start a new series of articles that will be posted every Monday.  This series will focus on the fugliest code ever created, and how it can, and probably should, be corrected.

Now I’ve worked in software development for a long time, and I’ve seen my share of fugly code.  That being said, I’m also certain that I’m not the only one who’s had to read through, debug and reverse design fugly code.  So I’m looking for examples from you, the coders out there on the internet.

Send us examples and snippets of the most horrendous, scary looking code that you’ve ever had the pleasure (or not) to work with.  Every week, we’ll pick the fugliest of the bunch and try and figure out what went wrong.  We’ll then attempt to demonstrate how it should’ve been coded in the first place.

So if you have fugly code, please submit it using the contact us form.

And be sure to visit us next Monday to see some of the fugliest code out there!

A note about submitting code:

Feel free to submit your code in any coding language.  If possible, try to make your code as readable and as generic as possible.  Do not submit any private, protected or copyrighted code. Remove any personal or sensitive information from the code and rename any variables to generic, non-descriptive names.  The goal here is not to steal code from others, but rather to try and find proper design solutions for poorly written code.

Remember the days before spam?

- Akismet

I remember my very first spam email like it was yesterday.  I was looking at my good old hotmail inbox and wondering why I never got any emails when suddenly, as though an answer to my prayers, I received an email from someone I didn’t know.

Being both naive and confused, I clicked reply, explained that I believed the senders had the wrong address, and clicked send.  It probably took a few weeks before I received my next spam email, and the next one came a few days after that, and the next a few hours, and so on.

Things are very different today, as spammers learn new tricks and spam takes on new forms, the tools at our disposal also evolve to protect us against such threats.  One of these tools is a blog plugin that I’ve been using since day 1 on my site, and will be the subject of today’s Blog Tools Review.  The name of the plugin: Akismet.

Why spam a blog?

If I had to guess, I would say that most people’s first encounter with spam is related to emails.  What’s important to remember, however, is that spam is not limited to email.  In fact, as a blogger, chances are that email spam will quickly become the least of your worries, and, without proper protection on your blog, you’ll soon be filtering through a barrage of comments to remove spam!

Now you may be wondering why a spammer would even bother with your blog.  The answer, simply put, is links.

You see, links on the internet are very important when it comes to increasing visitor traffic and increasing a site’s rank in search engine results.  It also turns out that blogs, by the very nature of their comment functionality, are a very easy target for spammers.

So how can I protect my blog?

Click above to see Akismet stats

Well that’s where Akismet comes in.  Developed by the same people who developed Wordpress, Akismet is a self-learning spam detection service that filters over 14 million spam comments a day.

It offers an API that is not blog engine specific (meaning you can pretty much use it on any blog), and is free for personal use (they also offer different plans for corporate and commercial users).

Setup is very simple, especially in for Wordpress users, as all one needs to do is install the plugin and provide an API Key.  Such keys are provided by WordPress.com and Akismet.com, are free for personal users, and are used to limit abuse of the spam busting tool.

Once installed, the plugin will begin filtering any new comments posted on your site.  Any comments deemed to be spam will be put in a separate folder from which you can review and correct Akismet if it makes any mistakes (although you may not have to correct it often.  On my personal site, for example, Akismet has an accuracy rating of over 99%.)

Review Recap

Pros:

• Easy installation for WordPress users
• Very efficient (over 99% accuracy) and learns from mistakes
• Very flexible, can be used with a variety of online tools
• Free for personal use and reasonable prices for professional or corporate use

Get more information on Akismet’s web site or the WordPress Plugin Directory

Articles of this series will be posted every Wednesday around noon ET and will focus on the different tools, themes and plugins that I commonly use to make my blogs easier to maintain and manage.  It was started on my personal site as a thank you to the open source community responsible for the creation of so many useful and free blogging tools, and will now become a regular part of FuglyCode.com.

If you have any ideas for blog tools that you’d like to see reviewed on FuglyCode.com, feel free to drop us a message using our Contact page.

View the first Blog Tools Review

View all Blog Tools Review articles in the series

What’s a plugin?

Before we jump into reviewing the different plugins that I use in my blogs, I think its a good idea to take a step back and understand what a plugin really is:

Lets say your blog is a small, old car.  When we were setting up the blog’s theme, we were actually doing things like giving the car a new paintjob, putting some new leather on the seats, and hanging a pair of fuzzy dice on the rear-view mirror (oh yea!).

Now that we have a pretty hot ride, we start to focus on making the car run, and begin installing upgrades like new tires, new suspensions and a lower frame.  These upgrades, while not changing the basic functionality of the car, make it run smoother, and to our taste.  This is the nature of a blog plugin.

So a plugin is a small piece of code that adds to or changes the functionality of your blog.  They come in all shapes and sizes (from simple to very complex), most of which are created and can be used for free on your blog.  With time, you will learn to master the art of including plugins on your blog seamlessly.  This will allow you to add new functionality to your blog, while not distracting your visitors.

Our First Plugin Review: WP-Cumulus

WP-Cumulus on Folaji.com

For our first blog review, we’ll be looking at one of my favorite plugins: WP-Cumulus.  This plugin takes your blog’s tags, categories, or both, and creates a 3D floating cloud of clickable links, which is then displayed in your blog’s sidebar.

Not only is the 3D rendered “cloud” visually appealing, it also engages your visitors, allowing them to skim through all of your blog’s content with the quick movement of a mouse.  The plugin is very easy to install and configure, and allows you to set the tag cloud’s colours and size to any RGB value.

For those of you that are concerned about the information being lost to search engine bots, WP-Cumulus will display a normal list of tags to any visitor that does not have Flash 9 or higher installed and javascript enabled.  Although some users might like this functionality, I see it more as a double edged sword.  Yes, the search engine bots will be able to crawl your site using tags, but this also means that anybody who doesn’t have Flash 9 and javascript enabled won’t see WP-Cumulus, but isntead will see the normal list of tags (which is not as professional looking as the 3D tag cloud itself).

So I say take the time to download and install this plugin.  Even if you don’t end up using it, its fun to setup and test (and who knows, you might just keep it on your site after giving it a test drive).

The WP-Cumulus plugin is available for WordPress self hosted blogs free of charge, and can be downloaded from the Wordpress.org Plugin Directory.

Review Recap

Pros:

• Beautiful and professional looking
• Very easy to install and configure
• Customizable height, width and colours
• Displays normal tag cloud to visitors without flash (useful for search engine bots)

Cons:

• Requires Flash 9 (or better) and javascript enabled
• May not be available to all blog visitors and browsers (ie: doesn’t seem to work in Internet Explorer 6)

Download WP-Cumulus here!

As you can see, our site is quite empty at the moment, and that’s mostly because we just launched.   Rest assured that we are working very hard at preparing some interesting articles about good software practices, common development issues, and, of course, fugly code.

So please bear with us while we get ready.