Coding Style

Do we really need properties in C#?

Changhong Fu — Tue, 02 Dec 2008 05:42:44 GMT

Last week, I had a discussion with some friends about the new features in C# programming language. It is kind of interesting that for most of the new features, I always found myself start with some sort of reluctance and then gradually accept it and finally find myself couldn’t write code without it. When I started learning C# a few years ago, I didn’t even like properties (I was a big fun of java). I didn’t understand that if they are just getters and setters, why we were bothered to have properties and let the complier hiding the truth? But now, I can’t imagine how I can write program without them. In my discussion, I told my friends that now I so much prefer the syntax of counter.Count++ over counter.setCount(counter.getCount() + 1).

Today, I suddenly realised that have given a very bad example. It actually shows the opposite of my point.

Yes, we all agree that counter.setCount(counter.getCount() + 1) is very ugly syntax, as a programmer who only write beautiful code, we all unhappy with it. So, it will make us to think, how can we make it better, should the getter and setter exist at the first place, isn’t it a clear sign of breaking the Law of Demeter? Then we may come up with better solution like this:

public class MyFancyCounter

{

private int count;

public void Increase()

{

count++;

}

As for counter.Count++, we are so happy with the syntax, we are probably never going to think if we should expose Count as a property, even though it does exactly the same as counter.setCount(counter.getCount() + 1).

So, with properties, life is easy. And it is so easy, that we are going to expose every single field as a property. In C#3, it is made even easier by have this syntax:

public int Count { get; set; }

By the way, can anyone tell me is there any real difference between public int Count { get; set; } and public int Count;? To me, they are the same. But as we all know public fields are very bad and we all love the ease of the public fields, this feature is kind of making compromise so that we can have public fields without feeling guilty. I remember a couple of years ago when this feature was demonstrated in a meeting, people were so excited and cheering loudly. I didn’t understand why people love it so much, are we going to tell our boss that we can finish the next project on time because we don’t have to type in all the properties?

Encouraging unnecessary exposure of private fields is not the only problem. A property gives impression of that it a simple field access, but in fact it is a method and it can do arbitrarily anything. Sometimes a property can cause great confusion when it is not supposed to be a property. Here is a real world story I can share. When I started working on a system a year ago, I found some services were suffering badly from memory leak. After running the service for a couple of hours, its memory usage shot up from 20M to 600M. With some help from Windbg/SOS, I found that all the WCF Channel objects were never got freed up. When I looked the code I find this pattern is used throughout the whole system:

ISecurityService service = serviceManager.SecurityService;

User[] users = service.GetUsers();

When I jumped into serviceManager.SecurityService, the code was something like this:

public ISecurityService SecurityService

{

get { return _securityFactory.CreateChannel(); }

}

The SecurityService property actually created a new instance of Channel every time it gets called! And as the factory object maintains the reference to all the channel objects it created, if you don’t explicitly dispose a channel object, it will never be garbage collected. So the correct way of using SecurityService is this:

using (ISecurityService service = serviceManager.SecurityService)

{

User[] users = service.GetUsers();

}

But do you feel it just looks wired? Yes, because you feel you are disposing a private field of serviceManager which might be used by someone else. I guess that is why everyone was deceived by the serviceManager.SecurityService property. So in this case, changing SecurityService property to method will make things much clearer. Like following:

public ISecurityService CreateSecurityService()

{

return _securityFactory.CreateChannel();

}

and

using (ISecurityService service = serviceManager.CreateSecurityService ())

{

User[] users = service.GetUsers();

}

Despite of the title of this post, I have no intention to challenge the existence of properties in C#. I love to use properties myself, even this one: public int Count { get; set; }

What I really want to say is sometimes to use a property is not a simple choice. When you enjoy the ease of the syntax you should ask some questions:

Do I really need to expose a field as a property?
Is it semantically very different from a field access?
Will the operation be much complicated than a field access?
Will calling the getter have a side effect?
Will the getter return different result every time it is called?

Code smell – many usings

Changhong Fu — Fri, 28 Nov 2008 15:55:53 GMT

If you see some code like this, you know there is something very wrong.

Why on earth should I have to deal with System.Xml, System.Threading, System.IO, System.Diagnostics, System.Runtime.InteropServices, System.Security.Cryptography, System.Net, System.Net.Sockets in a Form class?

Thoughts on programming language and maintainability

Changhong Fu — Wed, 10 Sep 2008 12:25:44 GMT

Recently, I have been working on maintaining two “legacy” systems. One is in VB6, implemented by a person who was not a programmer, but only trained a few weeks for VB6. The code quality is extremely poor. There are even no indentations in the code, and all variables are not properly named, for example, if there are 5 text boxes on a form, they will be just named as Text1(0), Text1(1)…Text(4). So, I guess I don’t have to say too much and you get a picture of what it looks like. Another system is done with .NET 1.1 using C#, and it is written primarily by a guy who, is considered as a coding hero or maybe, more precisely, a coding cowboy. I didn’t work with any VB stuff before this one, and I have been using C# for 4-5 years.

So, how easy I found maintaining these two systems? This probably will surprise you, but I do find maintaining the VB system is much easier.

Why I find maintaining the VB system is easier? Let me tell you what I normally do to fix a bug. Normally, I will start from finding the form. All the form files are inside one folder, and thank god, they are named properly. So it is not a big deal to find it. And then I will find the control, normally a button which triggers off the function which has a problem. I will then double click on the button, and it will take me to the event handler in the code view. There are normally at least a few hundred lines of spaghetti code. I do sometimes find it is a bit frustrating to work on some code like this, but I will tell myself to be patient, and normally it won’t take too long to locate the line has problem, and fix it normally not a big problem, and I won’t have to worry about fix this one will cause another ten bugs elsewhere because there is no code sharing at all.

While, fixing a bug in the .NET system is completely a different story. Normally finding a file is a big challenge. There are more than 50 projects in the solution (not because the system is large, it could be just 5 – 10), a project may contain only one file, but there are 10000 lines code in it and dozens of class definitions. There are interfaces which you will never find what class implemented it, and there are stuff may be loaded into system via reflection on runtime. There might be some super complicated and wired inheritance structure. Sometimes I get impression, that it is designed not to be found. I don’t want list of the problems here, I guess everyone has worked on this kind of system knows what I am talking about.

The point I want to raise here is, in term of maintainability, maintaining a well implemented object-oriented system might be easier than a well designed procedural system, but maintaining an object-oriented crap is even more difficult than doing a procedural crap. Also, no architecture is generally better than over-architecture. I think there are some reasons:

An object-oriented language itself is more complicated than a procedural language. The cool features like inheritance and polymorphism are all adding complicity and indirection into the program. Note, complicity and indirection are very bad thing, so if they don’t buy you anything, they should not be there.
A procedural language might not express well (spaghetti code), but it doesn’t lie, but an object-oriented language does. It could deceive you by using cool stuff like inheritance, reflection, delegate, extension methods, etc.

So, don’t take it for granted that an object-oriented language will automatically make your system more maintainable. What does make an object-oriented language work is the “loose coupling, high cohesion”, is single responsibility principle, is the open-close principle. It is not the cool language features or cool design patterns.

Turn off Resharper’s suggestion of using implicitly typed locals

Changhong Fu — Mon, 08 Sep 2008 11:24:22 GMT

If you use resharper with Visual Studio 2008, you may have noticed that it keeps suggesting you use implicitly typed local variable declaration i.e. the var keyword. To me, it is a bit annoying.

You can actually find why people think it should exist in the first place:http://resharper.blogspot.com/2008/03/varification-using-implicitly-typed.html

There are some valid points, but I am not convinced. I think it is less readable in most of the case. I can’t agree with Ilya that it induces better naming for local variables or better API. You got to name your variables properly no matter what you use, right? It won't make a good programmer better, but it will make a bad programmer even worse.

I do agree that compare to

Dictionary<string, Employee> employees = new Dictionary<string, Employee>();

That var employees = new Dictionary<string, Employee>();

does have same readability and it does save you a few key strikes. The benefit is really small, and you have to make judgment on it. The problem is you may have different ideas at different time and different team members may have their own habit. So, in your team, if the coding standard is “Use var whenever you think it good”, it will inevitably cause inconstant coding style. I would rather avoid it by having “Never use var”, you would lost too much after all.

So, if you don't like it neither, this is the way to turn it off. From “Resharper” menu, go to “Options…”, and from “Code Inspection”, then from “Inspection Severity”, find "Use Var keyword when possible” and set to “Do not show”