Head.SmackOnTable();

Well I have made my decision regarding my current position, at GHORG - I have decided to hand in my resignation.

Mainly because I am not a maintenance programmer, I did not join up to the company to clean crappy code from people who THINK they can code, but infact just do really stupid mistakes like:

The tip is the fact that your passing it the USERNAME, then pulling the USERNAME. Maybe you can just use that variable? But noo, they would be expecting that, Ze Germans.

File Naming

Me thinks my naming convention is getting a bit long...

But I am following my convention...is that a good or bad thing?

And longer, and longer... 

And keeps going, and going, and going, and going and going...

Embracing Generics!

Instead of repeated statements like:

I can now do :

by utilising:

Im really starting to get the hang of generics, I think theyr quite funky and cool!

One thing I dont see that often in code thats in production, is what I like to call a "Chain of Inheritance" - where classes inherit from one another, to add features to them, but only where those features will only benefit certain items, let me explain:

For one of the features for my resharper plugin, we have at the top of the chain, a "BaseBulbItem" which contains all the gubbins of the system:

From that, a Case Sensitivity bulb item inherits, also an abstract class. A reason for making this into its own abstract class is because I might not need Case Sensitivity for ALL of my coding standards (Not ALL coding standards are about case sensitivity after all):

For this to work, the interface HAS to implement IElement, IModifiersOwner and IDeclaration (Because IDeclaration gives you the DeclaredElement, which you need to refactor, IElement is the actual element, and what isnt listed above is the IModifiersOwner, which gives you the access rights)

From there, we can create a concrete class like the following:

Which gives us :

PropertyDeclarationCaseSensitiveBulbItem : CaseSensitiveBaseBulbItem : BaseBulbItem 

Which will finally give us the ability to work on Property Declarations, with very minimal code (infact I only wrote the class name, and the inheritance, VS.NET did the rest (except the text string). Its alot smoother and easier to create multiple bulb items now based around the same idea, which I had done for Method declarations etc...

I think is the correct way to inherit from a generic, and still have a generic interface, if that makes sense? (Made more sense in my head)

And yes, this is all work for my new all singing and dancing coding standards plugin for Resharper!

Thats what I worked out how to do yesterday, thanks to google. Its great :)

The "where" clause denotes the constraint on the Interface (i.e. the T type), so you can limit it to things that only implement from an Interface or an abstract class, or a class etc etc etc...its quite nifty!