Decaying Code

Where code comes to die

About the author

Maxime Rouiller is a passionate .NET technology specialist, working for 7 years in large software development, advocating Agile and TDD. Aware of the latest technological trends, he intervenes as a specialist in the .NET Montréal usergroup and acts regularly as a speaker for Web Form programmers on the MVC platform.

View Maxime Rouiller's profile on LinkedIn

Month List

Improving code quality - 2 ways to go

I've been thinking about this for at least a week or two. In fact, it's been since I started (and finished) reading the book "Clean Code" by Robert C. Martin. There is probably only two way to go.

Fix the bad code

This method is called refactoring and "cleaning" the code. This of course, you can't truly know what code is bad without having a Static Analyser tool or programmers working on the code. The tool will allow you to spot piece of code that could bring bugs and/or be hard to work with. The problem, refactoring code or cleaning up code is really expensive on a business perspective. The trick is to fix it as you interact with the code. It is probably impossible to request time from your company to fix code that could cause bugs. If you ask your company to fix the code, you will probably receive this answer: "Why did you write it badly in the first place?". Which brings us to the other way to improve the code quality.

Don't write it

If you don't write the bad code in the first place, you won't have to fix it! That sounds simple to an experienced programmer that improved his craft with years but rookies will definitely leave bad code behind. Eventually, you will have to encounter this bad code. So how do you avoid the big refactoring of mistakes (not just rookies)? I believe that training might be a way to go. When I only had 1 year of experience in software development, I was writing WAY too many bad code. I still do. Not that I don't see it go through. Sometimes, things must be rushed, I don't understand fully the problem and some small abstraction mistakes gets in. I write way less bad code then when I started. However, this bad code is not just magically disappearing. It's stays there.

What about training?

I think that training and/or mentoring might be the way to go. Mentoring might be hard to sell but training is definitely not that hard to sell. Most employees got an amount of money related to their name within a company that represent training expenses that can be spent on them. What I particularly recommend is some courses in Object-Oriented design or Advanced Object-Oriented Design. Hell, you might even consider an xDD course (and by xDD... I mean TDD, BDD, DDD, RDD, etc.). Any of those courses will improve your skill and bring you closer to identifying clean code from bad code. Other training that will form you specific framework (like ASP.NET MVC or Entity Framework) will only show you how to get things done with those framework. The latter can be learned on your own or through a good  book.

So? What do you all thinks? Do you rather have a framework course or a "Clean Code" course?


Permalink | Comments (0) | Post RSSRSS comment feed

PostSharp - The best way to do AOP in .NET

Who knows about Aspect-Oriented Programming (AOP)? Common! Don't be shy! Ok, now lower your hands. My prediction is that a lot of you didn't raise their hands. So let's resume what AOP is:

Aspect-oriented programming is a programming paradigm that increases modularity by enabling improved separation of concerns. This entails breaking down a program into distinct parts (so called concerns, cohesive areas of functionality). [...]

So what does it mean truly? Well, it's a way to declare part of your software (methods, classes, assembly) to have a "concern" applied to them. What is a concern? Logging is one. Exception handling is another one. But... let's go wild... what about caching, impersonation, validation (null check, bound check), are all concerns. Do you mix them with your code? Right now... you are forced to do it.

The state of current AOP

Alright for those who raised their hands earlier, what are you using for your AOP concerns? If you are using patterns and practices Policy Injection module, well, you are probably not happy. First, all your objects need to be constructed by an object builder and need to inherit from MarshalByRefObject or implement an interface.

This is not the best way but it's been done in the "proper" way without hack.

What is PostSharp bringing?

PostSharp might be a "hack" if think so. Of course, it does require you to have it installed on your machine while compiling for it to work. But... what does PostSharp does exactly? It does what every AOP should do. Inject the code before and after the matching method at compile time. Not just PostSharp methods but any methods that is inherited from the base class PostSharp is ofering you. Imagine what you could do if you could tell the compiler to inject ANY code before/after your method on ANY code you compile. Think of the possibilities. I'll give you 2 minutes for all this information to sink in... (waiting)... got it? Start to see the possibility? All you need to do is put attributes on your methods/attributes like this:

[NotNullOrEmpty]
        public string Name { get; set; }

        [Minimum(0)]
        public int Age { get; set; }

Now look at that code and ask yourself what it do exactly. Shouldn't be hard. The properties won't allow any number under "0" to be inserted inside "Age" and "Name" will not allow any null or empty string. If there is any code that try to do that, it will throw a ValidationException.

Wanna try it?

Go download PostSharp immediatly and it's little friend ValidationAspects on Codeplex. After you have tried, try to build your own and start cleaning your code to achieve better readability.

And yes... both are Open-Source and can be used at no fee anywhere in your company.

Suggestion to CLR Team

Now, PostSharp force us to have it installed with the MSI for it to work because it needs to install a Post-Compile code injector (like some obfuscation tools). What would be really nice, is to be able to do the same thing built-in with the compiler. The compiler is already checking for some attribute already... I would love to have this "internal working" exposed to the public so that we can build better tools and, more importantly, better code.

UPDATE: I want to mention that PostSharp is NOT open-source. However is free unless you need to package it with your tool.


Permalink | Comments (0) | Post RSSRSS comment feed

Stop using those stupid Model example

Stop using Circle/Square/Rectangle, People/Employee, Car/Model  examples for models or example on how to use Object-Oriented Principles or any example at all.

There is plenty of "Open" model that you can use. Here's a simple list for those who needs inspiration:

  • Blog (Posts, Comments, Authors, etc...)
  • E-Commerce (Invoice, Order, Customer, Warehouse, Inventory, etc...)
  • Auction (Auction, Seller, Buyer, Reputation, etc....)
  • Bank (Account, Transactions, Customer, etc...)
  • News site (Article, User, Approver, etc...)
  • And so many more

Unless you are explaining what is OOP to total beginner that never did any of this, you should use more advanced model to explain practices, design patterns or anything else. Otherwise, we'll keep on babbling on stupid model how a Square is a Rectangle and so on.

The time has come to stop using 1st grade model to explain advanced concept. Most people should be able to easily pick one of the model I've shown above and display one element of the model to easily make it available to everyone.

Who's with me?


Categories: architecture | design | oop | rant
Permalink | Comments (11) | Post RSSRSS comment feed