System.String and new() constraint

Few days ago, my colleague was dealing with code that was loading a list of objects from DataReader. Basically, for every record, a new object was created like this:

T obj = new T();
//set some properties using reflection
result.Add(obj);

Of course, the method had new() constraint for type T. The method name was pretty generic, however the method couldn't handle scalar values like ints, floats, etc. (because it tried to set some properties through reflection). My colleauge changed the code and if the value was a scalar value (IsPrimitive seemed ok for us) the value from reader was casted to T and assigned to obj. My colleague mentioned that this method won't work for String because String doesn't have public parameterless constructor. To be honest, I didn't know that because I have never needed to write something like String str = new String(). I've always written String str = String.Empty. However, it seems really odd that you can't just say new String(). I asked about this issue on stackoverflow: http://stackoverflow.com/questions/2454914/system-string-why-doesnt-it-implement-parameterless-constructor.
I suggest you read this post. Discussion in answers is really interesting.

I asked this question and thought about this issue for few hours. In our particular case, the code was clearly wrong. We created another method for scalar values without new() constraint. However, I still think that lack of public parameterless constructor for System.String is a .NET flaw (yet, as I said, I have never had a need to use it ;)).

Pai Mei's Second Lesson: How to eliminate dependencies on static utility classes?

Good design is very hard to achieve. It is even harder to come up with a good design before starting to implement the application. We often end up with one big project that has lots of inner dependencies on its own classes. The problem arises when classes rely on concrete implementation of logger class or some static configuration class. Code in these classes looks like this:

public void FooBar()
{
    string foo = Settings.Default.Foo;
    // some code
    Logger.Log("bar");
}

When you need to move some logic to another project (the most common case is creating a library that implements some specific functionality), you have to break these dependencies. Unfortunately, it will take some time and you will have to change a lot of code.

However, it is possible to avoid this kind of dependencies. You could use some IoC container such as Ninject, without relying on specific implementation of utility classes. Unfortunately, you have to rely on specific IoC container. However, it is very likely that you will use the same IoC container for every project in your solution, so it shouldn't be a problem. After changing the code, it looks like this:

IConfigurationProvider configurationProvider = KernelContainer.Kernel.Get<IConfigurationProvider>();
ILogger logger = KernelContainer.Kernel.Get<ILogger>();

public void FooBar()
{
    string foo = configurationProvider.Foo;
    // some code
    logger.Log("bar");
}

Obtaining concrete implementation this way may not be the best pattern (compared to just marking properties or constructor with Inject attribute); however, this is the easiest change to make, without the need to instantiate every class through service locator.
Relying on interfaces and not depending on concrete classes will allow you to easily extract parts of your logic to external class libraries.
This style of coding has many more advantages that will be discussed in future lessons.

It's the wood that should fear your hand, not the other way around.

Pai Mei's First Lesson: How many method parameters is too many?

Welcome to Pai Mei's programming tutorial ;)

Lesson One: How many method parameters is too many?

Many times I see people struggling with maintaining their code because they have too many method parameters. They have lots of methods that take the same list of e.g. 8 parameters, and when it comes to adding another one, they have hundreds of places to change.

If your method has up to 3 parameters, it's probably ok.
If your method has between 4 and 6 parameters, consider creating a class which holds parameters that have something in common (thus limiting number of parameters).
If your method has more than 6 parameters, you have to find a way to limit their number. Creating a parameter object (as mentioned above) is the best way to achieve it.

Sticking to these rules will help you design better methods. They will be much easier to maintain.

And one more silver bullet. If you see methods that share common list of parameters, and what is more, all parameters create one logical object, consider creating a class that implements these methods. Remove the parameters by replacing them with class properties.

These two techniques are very easy to implement and dramatically improve your code design.

Since your arm now belongs to me, I want it strong. Can you do that?

Developer checklist

Every book about project managament in software industry starts with some sad statistics that sound something like this:

According to the Standish Group in 1995, only about 16% of software projects are successful, 53% challenged (that is cost overruns, budget overruns or content deficiencies) and 31% cancelled.

http://www.projectsmart.co.uk/why-software-projects-fail.html

Sometimes I think that it's just an excuse for incompetent project managers but let's assume that's sad true about software industry.
However, I must say that most software projects I worked on were successful in terms of customer paying for delivered software. I must admit that I've worked only in software houses and even if a client wasn't delighted he had to pay for the product.
As a developer, I'm not responsible for selling the product, I'm responsible for software architecture, maintainability and so on. From this point of view, many projects were huge failures. I don't have recipe for making successful software, but I know what leads to failure. If you don't follow this simple rules you will inevitably have lots of problems.
The rules are kind of best practices. I divided them in several sections ordered by their importance.

MUST-FOLLOW rules

1. Use version control system and more importantly learn how to use it.
   For example, if you work with SVN learn how to create branches, add properties, always write comments when commiting changes.
2. Create centralized error/exception handlers.
   I've seen so many projects that don't utilise this functionality. Distinguishing mark of such project is the need that every developer has to remember to catch exceptions in their routines, even though they mostly don't know what to do with them.
3. Log information about errors.
   This is connected with previous point but I want to emphasize proper error logging facility. Too many times I've seen code like this:
   

   public void LogException(Exception ex)
   {
       Logger.Error(ex.Message);
   }
   

   or:
   

   try
   {
       /* some code */
   }
   catch (Exception ex)
   {
       Logger.Error("Something bad happened");
   }
   

   If you don't know what really happened, you won't be able to deal with it. Remember, most errors will occur when application goes to production environment, not during debugging sessions.
   
4. Keep security in mind.
   If you work with sql database never ever let sql injection be possible in your app. If you work with directory service watch out for ldap injection. If you create web service - secure it. Never trust user input and never assume anything about the environment your app will be working in (or assume the worst).
5. Understand SOA if you really want to use it
   Service oriented architecture is very hard to implement properly. Many times people end up creating service that has thousands of completely unrelated methods or service that can take every argument and return every result. This is a real maintaince nightmare. What is more, if you publish your service definition it is almost impossible to change it without making breaking change. Services should be really well defined and many times it is just not the way to go. If you really don't need to publish some services to third parties don't do it.
6. Create good testing environment.
   If you don't have testing environment that is very similar to production environment you will fail. Deployment in production environment will be a nightmare and you will not meet your deadlines. I assure you.

SHOULD-FOLLOW rules

1. Don't mix presentation layer with application logic.
   It is repeated over and over but it seems that people will never learn. Sometimes it seems to be easier to put some logic in presentation layer but it is always bad decision.

MAY-FOLLOW rules

1. Unit testing / automated tests.
   Personally I consider it to be very important, but I've seen many projects that were well-written and had great architecture even though they didn't contain single unit test. What is more, they had almost no bugs. That's why I put unit tests only on "may" list.

These are my rules of creating software that has smaller chance of failure. Every time I forget rules from my "must" list I have serious problems. To be honest, few times I tried just to forget these rules and tried to create some workarounds because I considered implementing e.g. central error handling a breaking change to the code. However, I always ended up fixing it because breaking the rule had such a bad impact on the application. I've learnt from these examples that creating workarounds is just a waste of time. Unfortunately, it was learning the hard way. I hope you will find the list helpful.
Happy coding.

I am the key to the lock in your house or some thoughts about reflection and Singleton pattern

I wanted to present some thoughts about the Singleton pattern and assumptions you can make about it. This post also shows that using reflection is like going to the darkside ;)

Say, we have a class SingletonFoo that manipulates some PreciousResource. Access to PreciousResource must be synchronized and manipulation should be performed in critical section.

public class SingletonFoo : ObjectWithIdentifier
{
    private static int instancesCount;
    private static PreciousResource preciousResource = new PreciousResource();
    private static SingletonFoo instance = new SingletonFoo();        

    // Explicit static constructor to tell C# compiler
    // not to mark type as beforefieldinit
    static SingletonFoo() { }
    
    private SingletonFoo()
    {
        instancesCount++;
    }

    public static SingletonFoo Instance { get { return instance; } }        

    public void ManipulatePreciousResource()
    {
        // no need for locking, we are in a singleton!            
        Console.WriteLine("{0} is accessing the resource {1}", this, preciousResource);
        preciousResource.Manipulate();
    }

    public override string ToString()
    {
        return String.Format("{0} [instances count: {1}]", base.ToString(), instancesCount);
    }
}

For clarification here is ObjectWithIdentifier:

public class ObjectWithIdentifier
{
    private Guid uniqueId = Guid.NewGuid();
    public Guid UniqueId { get { return uniqueId; } }

    public override string ToString()
    {
        return String.Format("{0}, id: {1}", this.GetType().Name, uniqueId);
    }
}

ObjectWithIdentifier is only necessary for giving more meaningful output from the application.
We have a situation when someone creates Singleton and assumes that he may be sure that only one instance of this class exists in the system, so he doesn't have to synchronize access to some PreciousResource:

public class PreciousResource : ObjectWithIdentifier
{
    public void Manipulate()
    {
        //do something
    }
}

However, here comes the evil doer:

public static class EvilBar
{
    const int REPEAT_COUNT = 2;

    public static void BeNice()
    {
        Console.WriteLine("Now I'm nice");
        for (int i = 0; i < REPEAT_COUNT; i++)
        {
            SingletonFoo.Instance.ManipulatePreciousResource();
        }
    }

    public static void BeEvil()
    {
        Console.WriteLine("Now I'm evil!");
        for (int i = 0; i < REPEAT_COUNT; i++)
        {
            ((SingletonFoo) Activator.CreateInstance(typeof(SingletonFoo), true)).ManipulatePreciousResource();
        }
    }
}

When EvilBar is nice we get following output:

Now I'm nice

SingletonFoo, id: 7dbccd1c-4e74-4e1d-b762-104f4cbcb82b [instances count: 1] is accessing the resource PreciousResource, id: c2b4a8b7-80e8-46cf-b616-a3f45f0612d7
SingletonFoo, id: 7dbccd1c-4e74-4e1d-b762-104f4cbcb82b [instances count: 1] is accessing the resource PreciousResource, id: c2b4a8b7-80e8-46cf-b616-a3f45f0612d7

But what happens if EvilBar is trully evil:

Now I'm evil!

SingletonFoo, id: 5a829a65-580f-4cc2-b17b-2650f68e464b [instances count: 2] is accessing the resource PreciousResource, id: 8417a76b-a40b-4221-bd73-0b507ff059c9
SingletonFoo, id: 744eba58-9aa9-4ee2-97aa-ffd815c3832f [instances count: 3] is accessing the resource PreciousResource, id: 8417a76b-a40b-4221-bd73-0b507ff059c9

We have three instances of our Singleton class. One for singleton and two instance created with Activator.
Ok, the class was intentionally written to be evil. But was XmlSerializer written to be evil? Let's add another method to EvilBar:

public static void BeUnwittlinglyEvil(SingletonFoo foo)
 {
    Console.WriteLine("Now I'm unwittingly evil");
    Console.WriteLine("Foo before operations: {0}", foo);

    XmlSerializer serializer = new XmlSerializer(typeof(SingletonFoo));

    StringBuilder serialized = new StringBuilder();
    using (StringWriter sw = new StringWriter(serialized))
    {                
        serializer.Serialize(sw, foo);
    }

    SingletonFoo result;
    using (StringReader sr = new StringReader(serialized.ToString()))
    {
        result = (SingletonFoo) serializer.Deserialize(sr);
    }

    result.ManipulatePreciousResource();
}

After executing the method EvilBar.BeUnwittlinglyEvil(SingletonFoo.Instance), we get following output:

Now I'm unwittingly evil

Foo before operations: SingletonFoo, id: 5c4724bb-ac02-4300-9be6-70c86c5629fc [instances count: 1]
SingletonFoo, id: 58612540-6d6a-458a-8c0c-1f723117f9b6 [instances count: 2] is accessing the resource PreciousResource, id: e7a55b7f-4e62-4d1f-878c-499ec0387a31

The implementation looks weird, but that just an example what happens if someone serializes this class and then unserializes it. If the code is executed in different threads, you will run into synchronization issues.
In Pragmatic Programmer there is a nice quiz. Which of these things should never happen (answers are presented below the post):

1. A month with fewer than 28 days
2. stat("." ,&sb) == -1 (that is, can't access the current directory)
3. In C++: a = 2; b = 3; if (a + b != 5) exit(1);
4. A triangle with an interior angle sum \u8800 180°
5. A minute that doesn't have 60 seconds
6. In Java: (a + 1) <= a

I'm adding another thing to the list: singleton with more than one instance ;)
The point is, you always have to think about the things you can be sure about your code and about the ways people are using your code. The less you assume, the better.


List of things that should never happen:

1. September, 1752 had only 19 days. This was done to synchronize calendars as part of the Gregorian Reformation.
2. The directory could have been removed by another process, you might not have permission to read it, &sb might be invalid—you get the picture.
3. We sneakily didn't specify the types of a and b. Operator overloading might have defined +, =, or ! = to have unexpected behavior. Also, a and b may be aliases for the same variable, so the second assignment will overwrite the value stored in the first.
4. In non-Euclidean geometry, the sum of the angles of a triangle will not add up to 180°. Think of a triangle mapped on the surface of a sphere.
5. Leap minutes may have 61 or 62 seconds.
6. Overflow may leave the result of a + 1 negative (this can also happen in C and C++).

Syntax sugar, aop and things that mess up with you behind the scenes

The more I play with reflector, the more my head aches ;)
Suppose we have a simple class like this one:

class TestClass
{
public void SomeMethod()
{
Console.WriteLine("doing something");
}

public void SomeMethodWithArgs(int arg)
{
Console.WriteLine("doing something with arg {0}", arg);
}

public string SomeMethodWithArgsAndReturn(int arg, string str)
{
Console.WriteLine("again doing something");
return String.Format("result ({0} + {1} = <foobar>", arg, str);
}

public IEnumerable<int> SomeIteratorMethod()
{
int counter = 0;
while (counter++ < 3)
{
yield return 2 * counter + 3;
}
}
}

When I look at SomeMethodWithArgsAndReturn, in reflector it looks like this:

public string SomeMethodWithArgsAndReturn(int arg, string str)
{
Console.WriteLine("again doing something");
return string.Format("result ({0} + {1} = <foobar>", arg, str);
}

Cool, huh?
First three methods look the same in reflector and in code. But what about SomeIteratorMethod? It has that fancy yield statement. Well, it looks like this:

public IEnumerable<int> SomeIteratorMethod()
{
<someiteratormethod>d__0 V_0 = new <someiteratormethod>d__0(-2);
V_0.<>4__this = this;
return V_0;
}

I also have a new class:

[CompilerGenerated]
private sealed class <someiteratormethod>d__0 : IEnumerable<int>, IEnumerable, IEnumerator<int>, IEnumerator, IDisposable
{
// Fields
private int <>1__state;
private int <>2__current;
public TestClass <>4__this;
private int <>l__initialThreadId;
public int <counter>5__1;

// Methods
[DebuggerHidden]
public <someiteratormethod>d__0(int <>1__state);
private bool MoveNext();
[DebuggerHidden]
IEnumerator<int> IEnumerable<int>.GetEnumerator();
[DebuggerHidden]
IEnumerator IEnumerable.GetEnumerator();
[DebuggerHidden]
void IEnumerator.Reset();
void IDisposable.Dispose();

// Properties
int IEnumerator<int>.Current { [DebuggerHidden] get; }
object IEnumerator.Current { [DebuggerHidden] get; }
}

I've hidden implementation but that's just an implementation of an iterator. However, that's a lot of code compared to my simple yield statement.
Some time ago my friend said that he doesn't like most of the new c# 3.0 features (ok, yield was added in c# 2.0 but that's not the point) because that's just syntactic sugar and he wants to know what happens behind the scenes. My opinion was that I don't maintain msil/byte code so I don't care what happens behind the scenes.
BUT maybe i DO care? This post by Eric Lippert clearly shows that I care or at least I should ;)
Ok, that's an example of a compiler doing something behind the scenes, but what if we want to mess up with the code ourselves? Concept of aspect oriented programming and aspect weaver is this kind of messing up with code.
Let's look at PostSharp and create a basic example of logging of entry and exit to the method body. I've created a simple trace attribute using PostSharp:

[Serializable]
public class TraceAttribute : OnMethodBoundaryAspect
{
private void LogMethod(string beginning, MethodExecutionEventArgs eventArgs)
{
StringBuilder result = new StringBuilder();
result.Append("== ");
result.Append(beginning);
result.AppendFormat(" {0}.{1}(", eventArgs.Method.DeclaringType.Name, eventArgs.Method.Name);
//imma charging mah oneliner ;)
result.Append(String.Join(",", (from arg in eventArgs.GetReadOnlyArgumentArray() ?? new object[0] select String.Format("[{0}]", Convert.ToString(arg))).ToArray()));
result.AppendFormat(") -> [{0}]", eventArgs.ReturnValue);
result.Append(" ==");
Console.WriteLine(result.ToString());
}

public override void OnEntry(MethodExecutionEventArgs eventArgs)
{
LogMethod("Entering", eventArgs);
}

public override void OnExit(MethodExecutionEventArgs eventArgs)
{
LogMethod("Leaving", eventArgs);
}
}

I've added TraceAttribute to SomeMethodWithArgsAndReturn:

[TraceAttribute]
public string SomeMethodWithArgsAndReturn(int arg, string str)
{
Console.WriteLine("again doing something");
return String.Format("result ({0} + {1} = <foobar>", arg, str);
}

In the end when I run my app with:

(new TestClass()).SomeMethodWithArgsAndReturn(11, "twelve");

I get nice output:

== Entering TestClass.SomeMethodWithArgsAndReturn([11],[twelve]) -> [] ==
== Leaving TestClass.SomeMethodWithArgsAndReturn([11],[twelve]) -> [result (11 + twelve = <foobar>] ==

But now my simple method in reflector looks completely different:

public string SomeMethodWithArgsAndReturn(int arg, string str)
{
string ~returnValue~1;
MethodExecutionEventArgs ~laosEventArgs~4;
try
{
object[] ~arguments~3 = new object[] { arg, str };
~laosEventArgs~4 = new MethodExecutionEventArgs(<>AspectsImplementationDetails_1.~targetMethod~1, this, ~arguments~3);
<>AspectsImplementationDetails_1.PostSharpTest.TraceAttribute~1.OnEntry(~laosEventArgs~4);
if (~laosEventArgs~4.FlowBehavior == FlowBehavior.Return)
{
return (string) ~laosEventArgs~4.ReturnValue;
}
Console.WriteLine("again doing something");
string CS$1$0000 = string.Format("result ({0} + {1} = <foobar>", arg, str);
~returnValue~1 = CS$1$0000;
~laosEventArgs~4.ReturnValue = ~returnValue~1;
<>AspectsImplementationDetails_1.PostSharpTest.TraceAttribute~1.OnSuccess(~laosEventArgs~4);
~returnValue~1 = (string) ~laosEventArgs~4.ReturnValue;
}
catch (Exception ~exception~2)
{
~laosEventArgs~4.Exception = ~exception~2;
<>AspectsImplementationDetails_1.PostSharpTest.TraceAttribute~1.OnException(~laosEventArgs~4);
switch (~laosEventArgs~4.FlowBehavior)
{
case FlowBehavior.Continue:
return ~returnValue~1;

case FlowBehavior.Return:
return (string) ~laosEventArgs~4.ReturnValue;
}
throw;
}
finally
{
~laosEventArgs~4.ReturnValue = ~returnValue~1;
<>AspectsImplementationDetails_1.PostSharpTest.TraceAttribute~1.OnExit(~laosEventArgs~4);
~returnValue~1 = (string) ~laosEventArgs~4.ReturnValue;
}
return ~returnValue~1;
}

Wow!
Once again, I've got much more code but it's not in my source code. And once again do I maintain that code? Do I have to be aware of it? How much do I have to know about it?
So the answer can be: don't use any syntactic sugar, don't use aop. You're fine with your strings, ints and simple stuff. You understand how they work and you're cool with it. Are you? Did you know e.g. about this: String interning and String.Empty?
Eric Lippert's blog Fabulous Adventures In Coding is full of these stories. And just wait for c# 4.0 - Evil code of the day.

Time for final remarks or maybe just my opinion on this topic.
I really like syntactic sugar and I'm keen on learning aop concepts. The things I wrote about in this post are scary to me but I think we just have to deal with the fact that computer languages are complicated (even if they try to hide it) and concepts that are simple in everyday work hide their complexity behind the scenes. Look at c#. You've got transformation between c# and msil, you've got jit, clr executing all that stuff and somewhere deep, deep below the code you've written there are pure assembly instructions. Syntax sugar doesn't introduce that much complexity compared to all the other stuff that happens implicitly and we don't (have to ;)) know about.
Remember, there's no such thing as free lunch ;)

Stay away from these rocks we'd be a walking disaster

Some time ago my friend wrote a post about open - close principle - Open – Close principle / Object – Orientated Design in PHP. I hate to say that but there is something fundamentally wrong about the example in this post. I thought about it for a while and here are my thoughts on it.

Open - close principle doesn't encourage particular design - e.g. it doesn't say that it should be achieved through inheritance. Unfortunately, when you're into OOP, sometimes classes and inheritance and all that stuff cover the real solution. Imho, in example provided Image content type should not be hard-coded in particular classes. For me, content type is just a resource. For example, if you want to implement different language versions, you do it using resources, not through inheritance. You don't implement abstract Caption class and then EnglishCaption, FrenchCaption or PolishCaption. The same goes with content type of an image.
If you create base classes and mark methods as virtual (or you don't mark them as virtual because they are virtual by default like in Java), the point of doing it is to implement different behavior in particular classes. If you do it just to return different string and you don't implement any different logic, then maybe there is something wrong with the design.

Ok, that's the most important problem with the given example, but there also some more:

• abstract class is called AnImage, ImageBase or sth similar would be far better
• in every SendFileHeader in every derived class you are forced to write header("some type"), GetContentType as an abstract method and implementing SendFileHeader in abstract class as header(GetContentType()) would allow avoiding logic duplication
• and there is that SendToBrowserFunction that was better before the refactoring than after the refactoring, I'll describe it in more details below

Before the refactoring SendToBrowser looked like this:

public function SendToBrowser()
{
$strFileExtention = $this->GetFileExtention();
switch ( $strFileExtention )
{
case ‘gif’ :
header("Content-type: image/gif");
break;
case ‘jpg’ :
header("Content-type: image/jpg");
break;
}
$strFileContent = file_get_contents($this->fPath);
echo $strFileContent;
die();
}

and after the refactoring it looks like this:

public function SendToBrowser()
{
$this->SendFileHeader();
$strFileContent = file_get_contents($this->fPath);
echo $strFileContent;
die();
}

Before and after refactoring it has this nasty echo and even worse die. Yep, there is also that header function, but I guess changing these methods would be scheduled for further refactoring, because the author writes:

Our first implementation of Image class did not follow one other object orientated design principle. The Single Responsibility Principle.

Ok, let's get back to that switch that didn't follow open - close principle. Am I wrong or the switch logic looks for me like:

header("Content-type: image/" . $this->GetFileExtention());

What is more, the author states:

Why this class breaks the open-closed rule? If we need to send PNG image, we would need to change behaviour of SendToBrowser method and add new case to our switch statement.

Well, if we got rid of switch statement, the above code would also work for PNG. And if we came up to the conclusion that it doesn't work for some particular extension, I still think it should be implemented as a resource (some config file), not using inheritance.
Furthermore, GetFileExtension should be moved to File class, not completely removed.

I would also like to share some general thoughts. Imho, interfaces provide much better decoupling than abstract classes, especially in languages where you can inherit only one base class. Creating abstract class is more risky than creating interface. Also, too many abstract methods in abstract class lead to derived classes that have empty implementation of these methods. Creating interfaces is easier and more flexible.
Interfaces are also essential to loose coupling and technology that has been a real buzzword for some time now - dependency injection.

Eventually, I want to say that this post is not criticism of the author of the Image example. I'm quite sure that he understands open - close principle really well, but he just chose a wrong example. Or maybe I'm totally wrong and the cure is worse than evil? If so Hit me! Come on, hit me!

Programming - It's hard

I've just finished Martin Fowler's Refactoring: Improving the Design of Existing Code.
Great book with even better examples. That's the best one:

double getSpeed() {
switch (_type) {
case EUROPEAN:
return getBaseSpeed();
case AFRICAN:
return getBaseSpeed() - getLoadFactor() * _numberOfCoconuts;
case NORWEGIAN_BLUE:
return (_isNailed) ? 0 : getBaseSpeed(_voltage);
}
throw new RuntimeException ("Should be unreachable");
}

Imho, this book shows the most important thing about code that I have learnt during three years of working as a full-time programmer - quality of code DOES matter.
Heck, it matters a lot.
For me, the real revolution started after reading Ron Jeffries' Extreme Programming Adventures in C# or some time around it. I don't clearly remember if I was first into XP techniques and then read that book or whether I became a fiend of it after reading the book.
Clean, object oriented, readable code is my definition of pretty code.
When I read something like...

Use short names (like i, x) for variables with a short, local scope or ubiquitous names. Use medium length for member names. Use longer names only for global scope (like distant or OS interfaces). Generally: the tighter the scope, the shorter the name. Long, descriptive names may help the first time reader but hinder him every time thereafter.

... I just cannot understand how variable name "x" can do anything good. I really don't like variable names like i, x, var1, result11. They clearly show that someone wasn't thinking about the purpose of a variable. Imho, when you create a loop, call a variable index if it's index or at least idx. If you do that and begin to think about every variable name, you will improve your code. If you can't find appropriate name, maybe you should substitute it with a method call or change the way of thinking about solving a given problem.
The excerpt I quoted is from Seven Pillars of Pretty Code by Christopher Seiwald. I can't fight the feeling that the author tries to find a complicated solution instead of naming things appropriately and extracting functions. When I look at jam.c example, I can find many adjectives describing that code, but adjective pretty just can't come up to my mind.
The article by Christopher Seiwald is more than ten years old and it's not my aim to criticize the author. Maybe this article shows the way people were thinking about source code 10 or 15 years ago. I just wanted to show another view on code structure and other conventions that people follow.
In my opinion, source code should show programmer's intention. And here is another great example by Eric Lippert C# Round up.

Ok, but let's get back to refactoring. Martin Fowler says that before you start to refactor, you should have good unit tests. I cannot disagree with him, but I often find writing good unit tests really hard. Most systems I'm working with have architecture that makes unit testing a real pain. What is more, I often look at source code, and I see that it is properly designed and I can understand the author. The real reason is that unit testing is very very very hard and requires lots of experience. Here's a nice example - unit tests for Microsoft Enterprise Library (link).

Data — 56 tests will fail if you do not have Oracle installed. If you do happen to have oracle installed, you’ll need to manually open the Data\Tests\TestConfigurationContext.cs file and change your oracle connection settings.
Logging — EmailSinkFixture.LogMessageToEmail will fail, since you do not have access to our internal mail server. You can fix this by changing Logging\Tests\EnterpriseLibrary.LoggingDistributor.config on line 22 to reference different smtpServers and to and from addresses.
Security.ActiveDirectory — Tests will fail because you cannot access our Active Directory server. There are instructions about how to set up ADAM in Security.ActiveDirectory.Configuration.ADAM Setup. You’ll also need to change line 53 in Security.ActiveDirectory.Tests.TestConfigurationContext to reflect your ADAM setup.
EnterpriseLibrary — It is normal for several of the tests to occasionally fail. There are a few unit tests that are timing-dependent, especially in Caching and Configuration. These tests are testing whether or not something happens during a particular time interval, and sometimes the system delays the actions too long and those tests fail. If you rerun the test, it should work the next time. Additionally, our tests write to the event log, which occasionally fills up. If you begin to see a number of tests failing, check that your application event log is not full.

That's a nice suite of unit tests. Some DO fail, some don't. Run them if you like it...
Ok, it sounds like I'm making fun of Microsoft guys, but the point is that I also can't write good unit tests. The biggest problem I have is isolation of datasources, such as database of some kind or directory service.
Maybe using some kind of IoC would solve the problem, but it would require redefining the project design just because I want to write unit tests.
Currently, I'm refactoring without unit tests. I don't have confidence that I don't introduce new bugs or break existing functionalities. Sad but true. I cannot isolate directory service to some interface (without big changes in design) and I also don't have time to create and maintain domain controllers just for the sake of running unit tests on build server.
I hoped that I could find some unit test examples on Directory Programming .NET (especially here: http://directoryprogramming.net/files/3/csharp/entry24.aspx) but there are no interesting examples. Maybe because it's an example of CRUD and it would require integration tests, not unit tests.

When I started programming I thought it was simple. When I started working as a programmer and met real-life applications, it became clear that I didn't know anything about programming. Then there was some time when I thought that I learnt a lot and I really knew a lot about writing code and design, not about every possible technology, but I thought that technologies are similar.
Today, I feel that I have so much to learn and I see so many things that I should improve. I feel a bit overwhelmed, but, first of all, I feel excited and eager to learn all that stuff. Maybe "Programming - It's hard" should be changed to something as kitschy as "Programming - A quest for perfect code" ;)

Tomorrow I'm going on a two-week vacation. It's been a while since I last had a vacation and it could be hard not to think about programming at all (what bad could possibly happen?). Especially, when I'll be reading Pragmatic Programmer, The: From Journeyman to Master (talking about kitschy titles...) ;)

Don't add uninitialised data or check if it is not in md_rand...

Recently I blogged about static code analysis. I am learning more about it and when I have some more experience with nDepend I'll share some knowledge on this blog.
More than a year ago there was THAT story about random number generator in debian. Well, it was pretty funny and pretty serious. For me mostly funny ;)



And this is the famous revision: diff.
In comments the developer claims that Purify made him do it ;) I'm not saying that this is the effect of code analysis, it's just a funny story. Still...
The funniest part for me is that this bug existed for about two years before it was spotted.

For your consideration ;)

PHP MVC vs. C# ASP.NET or the cure is worse than the evil

I started programming using C++.
Then I was writing stuff in C, C++, Pascal, Java, C#.
When I wanted to get my first job I figured out that most students work as PHP programmers, so I borrowed a book about PHP, wrote a sample application and a month later I was a PHP programmer.
I must say that in the beginning I hated every single bit of PHP. I've never written an app that I din't have to compile in order to run it. These crazy PHP constructs such as $$. Wow, they're really crazy.
What is more, I have never written a web application before. I always wrote some console / desktop stuff.
However, after about 3 months of coding on a daily basis I was pretty comfortable with almost everything I was doing. Maybe not with PHP itself, to be honest - I have never become comfortable with this language, but whole MVC pattern and its connection with web interface is so intuitive and natural that it really became my world. I still think that navigation on web pages is far better than navigation in desktop applications. When everything is identified by URL and I can open every link in another tab, I feel comfortable with interface. When I have lots of buttons and no tabs to open, I feel crippled with interface.
When I see a link like /article/show/123 or /article/edit/123 and I have Article controller and methods like show or edit, I can just sit and write code I need. I just love that HTTP protocol is stateless. I love the fact that anyone who clicks the link, be it a real user or google crawler, sees (almost) the same content.
PHP also has great template frameworks, such as Smarty. It's very intuitive and readable. The most important this is that THAT guys ;) don't have problems working with it and can easily can change the markup without affecting application logic.
Even though PHP frameworks like Cake and basically all MVC frameworks are very intuitive (in fact we were using our own MVC framework), language that drives them is really crappy. I've seen lots of PHP code, even very good PHP, and I've never seen good object-oriented patterns. Yes, there were lots of classes, but concepts such as inheritance, static objects, interfaces or abstract classes are not a part of this world. Classes in php are quite important but they are not strongly related to each other. When I think of real OO classes, I think about inheritance, interfaces that they implement, I see that some of them are more specialized, while others represent some general ideas. PHP OO in my opinion is poor man's OO. The real power in php are its associative arrays.
If I ranted about PHP flaws in its implementation of OO and wouldn't say that I was a strong advocate of not using most of its features in PHP5, I would be very unfair with people developing this language. I was always a strong opponent of using private / public keywords. The main reason was that every time someone messed up with it, we got white page of death on production server. I consider private / public modifiers to be important while compiling the code, but they become completely unimportant during runtime. Even if you declare field to be private, you can still access it using reflection of some kind. In php, when you don't declare types of method arguments, concepts such as interfaces also don't mean anything. PHP function takes basically anything and then tries to execute some methods on it. You don't have to declare interface to be able to execute some particular method on a given object. Well, you just try to execute it.
I worked with php programmers who actually used to think about types of objects they passed to functions. All interface / abstract stuff WAS implemented in the logic but not in terms of keywords. It was convention over configuration, and it worked pretty well.
Unfortunately, when someone didn't want to keep the convention, we just couldn't force them to keep it. And hell yeah, I wanted all people using my code to pass only some particular interfaces as arguments. I was unable to do that.
To sum up, I think that PHP is crappy, but it has great MVC frameworks, nice templating systems and if you want, you can write really good code in it.

On the other hand, there are C# and ASP.NET. I must say that I just love C# 3.0. It has so many useful features, great attributes, lambda expressions, generics. Some things could be better in C# 4.0, but even now it is my language of choice. C# lets you write clean and descriptive code that you would not be able to write in PHP.
However, here comes ASP.NET. I'm not talking about ASP.NET MVC - I have no experience with it, I'm talking particularly about classic ASP.NET. Well, ASP.NET is such a poor abstraction that I still cannot understand how someone came up with this idea. The whole concept of WebForms is really far from what web is really about. How could they come up with a lifecycle like that: page lifecycle (click to see the picture). Honestly, how could anyone make such an unintuitive life cycle and say that it is easier for web programming because it's like WinForms programming?
Most ASP.NET developers think that ViewState and Session are perfectly good places for keeping variables responsible for page navigation. Yeah, it's so great when you click on a page and URL doesn't change. It's so easy to share content with other users. Crawlers also love it! And what is really cool, sometimes you have to debug your application to see what are your current arguments and then you may find out that e.g. you forgot to clear Session in some onclick event.
And the whole gridview thing. That's a neat idea. Take everything from any datasource you have (e.g. 10 million records from a database) and do all things like filtering, sorting, paging, etc. yourself! Furthermore, keep all data in ViewState.
Seriously, how could anyone come up with that?
Everybody knows that webpage is like a real desktop application and all actions should be seen as events, e.g. click. Everyone agrees? Great.
Templating engine? We will show how hard could that be. Even tags are messed up: inline tags.
Crossbrowser issues? Only in asp.net. Yeah, there are lots of controls that work in IE, but don't work in FireFox.
Someday, I will come back to asp.net issue. In this post I just wanted to show how crappy it is. In my opinion, when you write web apps in php, ruby or python, you feel that you're writing for the web. When you use ASP.NET, you're writing these stupid webforms.
To sum up, C# - great, ASP.NET - yuck.

And here comes the final conclusion.
If I had to write a web application that goes public (not some intranet application) I would choose...


... PHP + MVC. I'm really sure that the result would be far better using that technology.

If I had to choose a job and I could choose between using these two technologies I would choose...


... C# + ASP.NET. It's better paid and you have chances that you'll be writing some underlying layer in C# and you don't have to deal with ASP.NET.

I must check this ASP.NET MVC stuff. I hope it will solve all issues of classic ASP.NET.
Remember kids, choose the right tools for the job and keep in mind that all that glitters is not gold ;)
Q.E.D., Bitches!

Prisoner of ice

All software companies talk about quality of their products. Quality is such a buzzword - sometimes I think that it doesn't mean anything at all.
However, quality means a lot to developers. Many developers that I know really care about products that they create, often against their managers and their companies. I understand when managers decide that they cannot spend more on some particular product, but I cannot understand a situation when a company makes developers work on some unimportant documents instead of making them focus on their work and implement the real thing.
I often encounter a situation when best developers in the team are assigned to create some specs in the early stages of development (often they have to analyze problems that they don't fully understand before the implementation), and people who are responsible for the actual implementation are unexperienced folks that have to learn how to solve problems during the project.
During the development everybody is in such a hurry that all tools and practices that are necesarry to create quality product are abandoned. This means no unit tests, no code reviews, etc. The project just flows. Because people who are developing it don't have any experience, they cannot solve even simple problems, they make obvious mistakes, copy code and everything becomes an awful mess. The project runs behind the schedule and, what is more important, it doesn't ensure any quality at all. After struggling with deployment, the product goes public and bugtracker is filled with bugs.
Unfortunately, because the budget was exceed, all funds are cut and people working on the project don't think about ways to heal it, but they start reading the specs, trying to persuade the client that the project meets specification requirements.
In this stage we can hear a bunch of silly questions, such as:
Do we have to log errors?
Do we have to support firefox?
Do we have to show error messages to users?
Do we have to validate input?

Well, the specs don't say anything about it. What's the conclusion? The project is just perfect. The only problem is that it just doesn't work.
After wasting lots of time on trying to vainly persuade the customer that it's not a bug, but it's a feature - the company faces the fact that they have to solve these problems. Unfortunately, as I've said before, they don't have any funds left. What is more, they discover that time spent on fixing the product generates loss, but if the developer does nothing or does not report his time on this particular product, no loss is generated. Now, the biggest issue is reporting the time spent on fixing the product. On paper it is better to sit and do nothing than to fix the damn thing.
It's like putting handcuffs on developers' hands. You just can't do anything. You know how to fix it, you have the idea, you know what you need, but you can't do it because, magically, the moment you report your time on the project, you start generating loss.
And the so story goes...

In my opinion, these problems are encountered in companies that are focused only on making money and they forget that they are making software. In the end, developers have to think about the budget and all that stuff around cost management, not about making great software. As the result, software is crappy and the income is far smaller than it was initially expected.
I have no experience running any company and maybe I am totally wrong, but I can tell bad software when I see one. And when I see developers that are prisoners of their projects, managers and procedures, I wish all project managers would be like Ron Jeffries or Joel Spoolsky. I wish developers could create applications that delight customers, create code that speak for them, have specifications consisting of test cases and work with the best programming teams in the world ;).

Nobobody wants to be THAT guy

Yesterday Jeff Atwood quoted some excerpts from Michael Braude's post Why I’ll Never Be A ‘Web Guy’ on his blog.
Of course it led to some flame wars about the question whether being a web programmer means to be a bad programmer or stupid programmer or anything else.
I must say that I completely disagree with Michael Braude's post. Especially with the hypothesis that web programmers are worse than desktop programmers. I cannot see the line that is between web and desktop programmers. Are there any big apps that don't connect with webservices or don't get any resources from the web?
Well, maybe I misunderstood Michael's post because in one of his comments he says:

I don't consider server-side programming "web programming" because SOA encompasses all mediums. Once you get into writing web services and DAL's you've left the world of aggravation.

So what the hell is he talking about? About creating simple html pages? Writing some javascripts?
In a company where I worked previously there was position called HTML programmer. We were making some jokes about it, because we, backend developers - "the real programmers" - didn't consider html to be a programming language. Due to popularity of XHTML we said the position name should be changed to XHTML programmer, however one of the HTML programmers left the job before the renaming took place and was claimed to be first ex-HTML programmer ;)
I must say that I really liked this distinction. I never had to deal with CSS or divs or anything. I just prepared some basic html (mostly including table layouts ;)) and then the template went to HTML guy and he prepared some decent looking webpage.
I always thought that HTML / javascript guys were not real programmers. They often didn't know how to program but they were never responsible for application logic. I never wanted to be a HTML guy and I never was. However, I would never say that they are better or worse than backend programmers. The reason why they wrote HTML was because they liked it, they chose this job, not because they weren't smart enough - they just had different skills.
I know good and bad html programmers. I think that writing good html and css requires lots of skill and I appreciate their work.
I don't consider c# / php guys smarter than html guys. On the other hand, I do think that being frontend developer is far less demanding that being backend developer. But that's just my opinion. If I say that being windows administrator is far easier than being unix administrator, I am not saying that windows administrators are dumber that unix guys. And if I needed windows administrator I would hire one. I would not hire unix administrator for this position because I think that his previous job was more challenging.
The problem with Michael Braude's post is that he somehow says that html programmers are inferior to backend developers. I am also considering their JOB inferior but I don't consider THEM inferior. Still, that's only my personal view on job market and it also reflects my ambitions and aims in my career as a developer.
The last remark is that people who use easier tools aren't dumber than people using the tools that are harder to maintain. What is more, maybe they choose better technologies and more powerful toys and in this way they are far smarter than people who think are intelligent enough to reinvent the wheel from scratch.

Unstoppable force meets immovable object

Code generation - here I come, once again.
Once upon a time I had to create a cms system. The system was quite large and I had to do it in about one month. What is more, the main reason I was creating the new system was to fix the issues we had with the old one. The point is that I had really not enough time.
However, I was able to create quite a decent application. I was rather satisfied with the result and the system didn't have a lot of code repetitions in its core.
Most of the logic was handled by business classes and they implemented good abstraction, i.e. versioning, cache and such stuff were implemented in base classes. However, the project had similar controllers and models (models in framework I used were something between a classic model and controller) for every module such as article, news, banner, etc. Due to a short deadline I was literally copying the files and changing names in them using replace function in IDE. Then, when I had some time to work on that code I changed all literal strings and other things specific to modules to constants that pointed to configuration in particular modules. My aim was to create classes that didn't force me to think while I was replacing text in source files, e.g. instead the sentence "Article has been added successfully" in template file I started using something like $moduleConfig[ARTICLE][TEXT_ADD_SUCCESS]. Well, that was my poor man's code generation. It had all the features of code generation besides the generator ;) At least I didn't have automatic code generation but I was manually copying files from other modules that were my templates.
To be honest, we've never encountered any serious problems with this approach and it worked quite well. However, I always thought that if I were given a week or so to work on this code and refactor it to extract base classes for models and controllers, the project would be so much better. The project was crippled with the fact that the whole code for these controller and model classes was duplicated. Unfortunately, I was never given the time to fix it before I left my ex-company. Everything was prepared, base classes should implement all the logic and child classes would know who they were and what constants they should use.
That story showed me that code generation, when used improperly, may seem an easy solution to a problem that should be addressed in another way.
Every tiny bit of logic that is generated shows that it should be placed in another element in design or higher in inheritance hierarchy.

First observation - IMHO, no application logic should be automatically generated.

But what about classes that give us strong typing for a cost of code generation? I'm not talking about typed DataSets in .NET because they suck so bad that they are not even worth mentioning but let's talk for example about classes generated from SubSonic. In the simplest approach generated classes reflect tables in database and they have strongly typed fields that represent columns in tables.
What are the advantages?
- you won't misspell a column in a table
- you also won't assign e.g. a string to an integer
But what are the disadvantages?
- you end up having lots of code that doesn't implement any logic at all
- every time you change database schema you need to regenerate your database classes
- if you generate CRUD from it, you will have problem achieving good level of code coverage
- if you change field name in database and want to keep property name in class, you may get confused using different names for same thing

Sometimes I think that we are paying too much for strong typing. Maybe the IDE should check the database and automagically check source code? For example, when I was writing a simple program in F#, the IDE checked if I specified correct format in literal string that was used in the method. When I specified in string representing format that I was expecting int and the corresponding argument was string, the IDE was smart enough to discover this problem. What is more, even if you misspell some fields you must have not tested the application at all if you didn't find this error.

Some frameworks let you write code that goes pretty well without the need to generate code (e.g. PHP frameworks); others (like ASP.NET that needs to see every control as a variable with a type, name and all that stuff) may try to force you to generate some code. Of course, I'm not a big fan of the latter.

And one final remark. I don't consider operations performed by a compiler to be code generation. Generated code may occur only in source files that developers are maintaining. We don't maintain byte code or low-level assembly instructions. The same goes with different forms of syntactic sugar that are handled by compiler and translated to "normal code" behind the scenes.
My friend wrote a note about on his blog: http://binary.freeperspective.net/countzero/2009/08/14/code-generators/. He says that he will come back to this issue. I'm eager to read his thoughts about the topic of code generation.