Contents tagged with code
-
Returning to multiple exit points
My blog post on multiple returns and why they are actually quite useful has a small but enduring popularity (some of it negative) among those who obsess over minutia. Yes, that includes me sometimes.
For instance this blog post, which argues for single returns, with an example where a single return is better.
-
Deep indentation is still bad and wrong
I wrote a while back about how indenting trailing lines of code to match some semantic element of the line above was bad and wrong - it's inconsistent and hard to maintain, not to mention hard to get right initially and generally makes code harder to read unless you have a very wide screen. Continue reading...
-
RabbitMQ in .Net
With help from Ann, I did some simple demo programs over the last few months to try to understand RabbitMQ and message queues in general.
The code that we produced, (with a readme document) is here on github
RabbitMQ is a free, open-source cross-platform message queuing system. It is described as robust, fast and scalable though I didn’t really test those features since I just ran it on my laptop and sent a few tens of messages. In production it would run on a server, or on a dedicated cluster if a really large volume is required. It follows a standard called AMQP.
-
Ioc Comparison: Autoregistration in Autofac
Autofac is a capable and interesting IoC container. I looked at Autofac for basic IoC here. Implementing my suite of autoregistration tests in Autofac did not require any custom extension classes, autofac handled everything that I asked of it.
Autofac adds registrations in an atomic manner, like StructureMap. But Autofac doesn't use lamdbas - you configure a ContainerBuilder in as many steps as needed, and then create a container from this builder in a single operation.
-
IoC comparison: Autoregistration in StructureMap
The StructureMap IoC container has guidance on using Autoregistration which I followed. Earlier I put StructureMap through its paces for basic IoC.
For Autoregistration, StructureMap uses lambdas, even nested lambdas. The interface is not fluent. The basics are quite simple. StructureMap feels a bit like Ninject under the hood, and there are similarities – both do automatic resolution of unregistered types, and both need custom code to do more complicated Autoregistration scenarios. Both are perfectly usable with a bit customisation.
-
IoC comparison: Autoregistration in Ninject
The Ninject IoC container has an extension that does autoregistration, or "Convention based binding" as they call it. I have looked at basic IoC in Ninject before, and I quite like it. Autoregistration is not a third party add-on, but is part of the ninject source tree here on github. Ninject autoregistration does not work in quite the same vein as Windsor or Unity's fluent interfaces, but it feels like the "Ninject way", i.e. similar to the other parts of ninject such as using classes as modules.
-
IoC comparison: Autoregistration in Microsoft Unity
The Microsoft Unity container does not include autoregistration, so you could do without it, roll your own or use the Unity Auto Registration addon by Artem Govorov. This post looks at Unity with this addon. Like Windsor's autoregistration API, it also uses a fluent interface. Unity's fluent interface starts with the extension method ConfigureAutoRegistration, then follows one or more Include(FilterPredicate, Then.Register.As… ) blocks, and ends with ApplyAutoRegistration();
-
IoC comparison: Autoregistration in Castle Windsor
Castle Windsor emphasises autoregistration, probably more than any other .Net IoC container, and the API to do it is probably the most complete.
Windsor's explicitness about registration - the lack of automatic resolution of unregistered concrete types - turns out to be an asset with autoregistration. In a sense, automatic registration and automatic resolution are two different approaches to the same problem of convention over configuration in that they allow you to create types without mentioning them in the container configuration. But they don't play that well together, and can give confusing results.
-
IoC containers: Autoregistration tests groundwork
I have put together an assembly containing some types used to test the autoregistration features of different Inversion of Control containers.
I will put some IoC containers (starting with Windsor) through a set of tests over these classes. The IoC container will have to find a concrete class, find an implementation for an interface, and find all implementations of a interface where multiple types implement it.
-
IoC comparison: OpenRasta Internal Dependency Resolver
OpenRasta is an excellent .Net web framework written by Sebastien Lambla. OpenRasta is open source, is opinionated about REST, but is also highly flexible and configurable. So you can plug any Inversion of Control container into it, but it also contains a basic built-in IoC container that is used if no external container is supplied. Even though this container is not intended for use outside of OpenRasta, I decided to isolate it and put it through my IoC comparison tests.
-
IoC comparison: Spring.NET CodeConfig
Spring.NET has a new add-on called Spring.NET CodeConfig 1.0.1 that I hoped may adress some of what I saw as spring’s shortcomings in my comparisons of .Net IoC containers, specifically it should allow different configs be used in different tests in the same project. The docs for Spring.NET code config are here. it's also on github and nuget and is apparently just "the first step in the process of expanding Spring.NET's support for non-XML-dependent configuration scenarios". It works, and goes about it in a different way which is not as terse and as most other containers.
-
Duplicate finder
A while back (2007) I was challenged to make a duplicate code detector for C#. Simian did a valuable job, but cost money. And, someone said to me, how hard could it be? So I wrote one and put it here. I wrote about it here and here.
I learned these things about the problem of detecting duplicate code:
-
Thoughts on making coding standards
We've all done it. You're tired of the one colleague who always codes with a layout that you can't stand, so a coding standard is brought up. Before you do so, consider this advice:
-
The LightCore IoC container 1.4
I have looked at the LightCore IoC container before in this blog post reviewing it. Now Peter Bucher has released version 1.4.1 of LightCore.
I'm happy to say that this fixes the issue that I had with version 1.0 and things work smoothly.
-
The single exit point law
It is sometimes said that a method should have only one return statement (i.e. one exit point) and that to code using more than one return per method is bad practice. It is claimed to be a risk to readability or a source of error. Sometimes this is even given the title of the "single exit point law". Actually, if you want to call something a law, I'd expect some evidence for it. I do not know of any formal study that back this "law" up, or of any study of the multiple-return pattern at all. This makes it a "preference" not a "law". And it's a preference that I do not hold for c# code. Or java, ruby or python code either. Continue reading...
-
Indentation of trailing lines of code
I'd like to blog about a point of code indentation. I have a strong and unusual opinion on this topic, that the way that most people do it is ... less than best.
I suspect that about half of the readers will not want to read further, since they already know the right way to indent code (the way that they do it already, whatever that may be) and the other half won't want to read further, for fear of getting involved in the religious wars, lest the nits that I pick infest them too. But anyway, though de gustibus non est disputandum (that's Latin for there's no accounting for taste), consider the following as an option.
-
Comparing .Net IoC containers source is now on github
The source for the comparisons that I have done on IoC Containers is now on Github at http://github.com/AnthonySteele/IoCComparison Continue reading...
-
The LightCore IoC container
I have had a look at LightCore, which is written by Peter Bucher, who works in Germany and Switzerland. It is available with source, and has a public SVN repository. The documentation is in German, but it isn't hard to work out what the code samples do. Continue reading...
-
The Funq IoC Container
I was asked to look at Funq, an IoC container that aims to be lightweight and high performance, using lambdas and generics to eliminate the use of runtime reflection. It was made by Daniel Cazzulino (@kzu), and in a series of screen casts he shown the whole process of developing Funq using TDD. This is very impressive and may be a good introduction to TDD, but aside from this, there is little or no documentation. Videos are all very well, but they are no substitute for written code examples. So I may have missed how to do things in Funq. Continue reading...
-
Comparing .Net IoC containers, part seven: MEF
The Managed Extensibility Framework from Microsof is part of the .Net 4.0 framework, but is not an IoC container. Well, not quite, but so close that you might take it for one. It is an Extensibility framework. It really shines when you want to know about all the classes that implement some interface (say IPlugin or IApplicationPart), and get notified when a new one shows up at runtime. So you can get told about all the plugins or components that your application has been given. Continue reading...