Code Smells

From Wikipedia: “In computer programming, code smell is any symptom in the source code of a program that possibly indicates a deeper problem.”

We all need to get things done and most of the time we need to do them in a hurry. Unfortunately the result is that our code are not always a clean as it should be. Fortunately we are not alone in this world and other people experience the same problems that we do.

Code Smells are one of those things that can help us to identify when we are doing things that may hurt ourselves in the future. We may not always be able to fix them, but whenever you encounter a Code Smell, see if you can either justify it or fix it.

Code Smells are not the problem themselves, but they indicate that other problems exist in the code. Solving them is important, but it is even more important to understand why they are bad.

Code Smell for the week: Huge methods/functions

Whenever a method becomes too big it gets hard to follow the logic of the method. Such a method should be broken down into smaller methods that groups together related functionality. If the refactored methods then contains unrelated functionality, consider moving them to separate classes.

When doing the refactoring of big methods, it is common to encounter problems like the constant use of a shared variable throughout the method. This is in its own a Code Smell and may be mentioned at a later stage.

When is a method TOO big?

The size of a method is not the only determining factor. Whenever your method performs more than one definable thing, it's probably too big.

Another telling factor is the levels of indentation within the method. If you start having more than 4 levels of indentation in one method, you have good reason to believe that the method is too big. In methods that are too big, it can become very hard to follow the indentation levels.

Some things to consider:

1. Don't overdo it. Functions that are too small can hamper the readability of the code.
2. Don't expose functions to the global name space unless needed.

Please discuss Code Smells amongst each other. It is often more important to know why code smells are bad rather than knowing how to fix them. Knowing why they are bad will most likely result in us producing less Code Smells.

From the attic

Most programmers have a stash of old software projects somewhere. I decided to go and dig up those projects I have and commit them on github. They can all be found

Minesweeper (c++)
I wrote Minesweeper because of my ego back in 2002. A friend of mine was going on about how difficult it is to implement minesweeper, so I decided to see how difficult it could really be. It can now be found here. Here is a screenshot of what it looks like:

Tetris (c++)
This is another classic. Every aspiring game programmer (overeager teenager) have probably written a clone of Tetris. This was my attempt, it's called Blockys Bow, can't remember why I called it that? You can find the source here

Connect More than Three (java)
I enjoyed playing the plastic version of this game, so I decided that that's enough reason to create an intangible one. This was done in Java, some of my first code therein.



Snake (java)
Last and probably least as well. At some time in my life I was clearly bored, didn't have many friends or more disturbingly found it interesting enough, who knows? Point being, I implemented a snake like game in java. As you can see from the screen shot below, everything didn't work like is should. Enjoy the source if you want.



Well, that's all for today. If I receive any motivation (in the form of comments or your projects on github) I'll dig up that stash of pascal code thats lying around somewhere.

A visual haXe example

This example will show you how to create a simple maize-style background in haXe like the picture below:



First we need to create the maize graphic. We do this by extending the flash.display.Sprite class. Lets call the derived class MaizeBackground.

class MaizeBackground extends flash.display.Sprite
{
    public function new()
    {
        super();
    }
}

This will create an empty sprite that does not show anything. In order to add some graphics we must either add another flash.display.DisplayObject containing some graphics to the sprite (like a Bitmap, MovieClip or another Sprite) or we must draw something on this sprite using the graphics property of the sprite.

We are going to use the graphics property of the Sprite. So lets add a method called redraw to our class and use this to draw the maize. We should call to this method in the constructor:

class MaizeBackground extends flash.display.Sprite
{
    public function new()
    {
        super();
        redraw();
    }

    public function redraw()
    {
        graphics.beginFill(0xFFFFFF, 1.0);
        graphics.drawRect(0, 0, 800, 600);

        var color : Int = 0x000000;
        for (y in 0...60)
        {
            color = color ^ 0xFFFFFF;
            for (x in 0...80)
            {
                var prev = false;
                if ( Math.random() < 0.10 && !prev )
                {
                    graphics.beginFill(color, 1.0);
                    prev = true;
                }
                else
                {
                    graphics.beginFill(color ^ 0xFFFFFF, 1.0);
                    prev = false;
                }
                graphics.drawRect(x*10, y*10, 10, 10);
            }
        }

        var filterArray = new Array();
        filterArray.push(new flash.filters.BlurFilter(5, 5, 9));
        filters = filterArray;
    }
}

The logic for the redraw method is reasonably straight forward. We look at the maize as being divided into rows and columns.

1. Step through the image row by row.


2. Alternate between black and white rows


3. For every column in the row there is a small possibility of drawing the inverted color.


4. Finally we apply a blur filter to make the crude maize look a little better.

An important thing to note is that the filters only get applied when we assign something to the filters property of a flash.display.DisplayObject. If we simply pushed the new BlurFilter to the filters property, the filter would not have been applied.

Save this class in a text file called MaizeBackground.hx

Now we need to create a main class and add the sprite to the stage. Create a class called MaizeExample:

class MaizeExample
{
    static function main()
    {
        flash.Lib.current.addChild(new MaizeBackground());
    }
}

Save this class in a text file called MaizeExample.hx

Finally we need to create a compile file for the haXe compiler and compile the swf. Create a file called compile.hxml with the following contents:

-swf maize.swf
-swf-version 9
-main MaizeExample

Save the file in the same directory as MaizeBackground.hx and MaizeExample.hx and run haxe in that directory.

This should produce a swf file that can be opened using Adobe's flash player or browser plugin.

The MaizeBackground example could benefit from many improvements:

• Add size properties to determine the size of the maize.


• Play around with the different filters available in the flash.filters package


• Change the size of the cells to be determined by a property


• etc

Any comments or suggestions are more than welcome!

Installing NekoVM and haXe on Gentoo

Installing NekoVM and haXe on gentoo is done best by using the ebuilds provided by Daniel Turing.

To install the overlay, you need Layman and Subversion. Have a look at Gentoo Overlays: Users' Guide to set up layman if you haven't done so already and make sure you have emerged subversion.

Manually download the text file layman-haxe.txt using your browser or wget:

$ wget http://svn.xinf.org/haxe-gentoo-overlay/layman-haxe.txt

Open up the text file with your favourite editor and replace the line

src="http://xinf.org/haxe-gentoo-overlay"

with

src="http://svn.xinf.org/haxe-gentoo-overlay"

alternativeliy use

$ mv layman-haxe.txt layman-haxe.backup
$ sed 's#src="http://#src="http://svn.#g' layman-haxe.backup > layman-haxe.txt

now check out the overlay using

$ layman -o file:///path/to/file/layman-haxe.txt -f
$ layman -o file:///path/to/file/layman-haxe.txt -a haxe

You can now install the neko, haxe and swfmill that's in the overlay using

$emerge neko haxe swfmill

To install the latest version of NekoVM (1.8.0 at the time of this writing), you first have to create a local overlay. Follow the instructions on gentoo-wiki.com to do this.

Create the following directories in your local overlay: dev-lang dev-lang/neko dev-lang/neko/files

Copy 50_mod_neko.conf and 50neko from the layman haxe overlay into the dev-lang/neko/files directory. Copy this text into dev-lang/neko/files/neko-1.8.0-gentoo.patch. Copy neko-1.7.1-r1.ebuild from the layman haxe overlay to dev-lang/neko/neko-1.8.0-r1.ebuild.
(update: here is a link for the patch for neko 1.8.1)

Download neko-1.8.0.tar.gz into your distfiles directory. All that's left to do is to generate the manifest file. Use

$ ebuild neko-1.8.0-r1.ebuild digest

to generate the digest file. You will need to execute this command as a user with privileges to write to the dev-lang/neko directory.

Now you can emerge the latest version of neko!

Update: the haxe and neko ebuild together with the patches can now be found at github

Over to KDE4.2

After some initial struggles (gentoo-user mailing list) I have managed to update to KDE4.2.

I will not say that this applies to everyone, nor will I make a sweeping statement like "KDE is back", but, KDE is back on my desktop and I'm reasonably happy with it!

I'm using a reasonably dated machine, AMD Athlon XP 2500, NVidia GeForce FX 5200 128MB and 640MB DDR333. Not the greatest machine, but after disabling all desktop effects, things are running quite smooth.

I decided to give the new Kickoff menu a go since KDE4.1.3. Although it's not what I am used to, it is still not something that will completely deter me from using KDE4. After all, if I really can't adapt, I can always go back to the classic style menu.

There is however a few things that I think could be improved. The first thing is adding shortcuts to the bottom panel. I always keep a few icons in my panel - konsole, the home folder and firefox at least. When I wish to add an icon to the panel , the widgets need to be unlocked. I feel that even when the widgets are locked, you should still be able to add icons to the panel. Having different context menus depending on the locked status of the widgets are a big confusing. For me the main advantage of locking the widgets is the absence of that configuration bar next to desktop applets. But, this is also no show stopper, I only need to add shortcuts for my favourite applications once.

Another thing didn't work that great was Okular. I opened "Learning CMake", but it was painfully slow. I haven't had time to test it with another PDF reader like xpdf or kpdf, so maybe it's just the PDF document?

But overall I'm impressed with KDE4.2. From now on this will most definitely be my default desktop!