Month: May 2011

Cleaner Event Declarations in C#

The traditional event declaration in C# looks something like this:

public event EventHandler Executed;
protected virtual void OnExecuted()
{
    if (this.Executed != null)
        this.Executed(this, EventArgs.Empty);
}

The gratuitous null check in the virtual OnXYZ event caller has always pestered me and I just learned an interesting alternate syntax to avoid this boiler plate code! Behold the cleaner alternative:

public event EventHandler Executed = (o, e) => { };
protected virtual void OnExecuted()
{
    this.Executed(this, EventArgs.Empty);
}

When declaring the event start by assigning it to a lambda, then your event will never be null. Of course there is a minor performance impact to this, but we’re not prematurely optimizing right? Riiiiight?

Does process kill developer passion?

http://radar.oreilly.com/2011/05/process-kills-developer-passion.html

In general I agree with most of what he says, such as

In short, you’re spending a lot of your time on process, and less and less
actually coding the applications.

… having to shoehorn in shims to make unit tests work has reduced the
readability of the code.

Disaffected programmers write poor code, and poor code makes management add
more process in an attempt to “make” their programmers write good code. That
just makes morale worse, and so on.

The blind application of process best practices across all development is
turning what should be a creative process into chartered accountancy with a side
of prison.

And as an aside, if you’re going to say you’re practicing agile development,
then practice agile development! A project where you decide before you
start a product cycle the features that must be in the product, the ship date,
and the assigned resources is a waterfall project.

However I strongly disagree with this

But, for example, maybe junior (or specialized) developers should be writing
the unit tests, leaving the more seasoned developers free to concentrate on the
actual implementation of the application.

But I would like to say that I really do love TDD, as I am working on this new version of MetaSharp I am really driving it with tests as best as I can. Tests are critical for verifying that your code is actually correct and that some new feature doesn’t break something you have already done. That being said it’s really only useful in a project where you know where you are going already. When I first started MetaSharp there was a lot of experimentation and a plenty of dead ends and when I wrote a lot of tests it was a mostly just wasted effort to undo and redo the them, it was a pain in the ass frankly. But after a lot of prototyping and experimenting I finally decided that I knew where I wanted to be and started over. In this new iteration I have been writing as many tests as I can without slowing my momentum down too much, and the thing is  when you know the domain and where you need to end up the tests do not slow you down at all. It’s excellent in that scenario. So I think if you go into a coding phase with a prototyping mentality then, meh, maybe TDD is more of a hindrance but seriously be prepared to throw it all away. The quality just wont’ be high enough without extensive tests. It’s not a foundation to really build too much ontop of.

But TDD is really only part of the story. I’m not in a position to dictate our development process on my team at work so I’m trying to analyze it and find out what I like and don’t like because you can learn about as much from what doesn’t work as you do from what does work. I feel like we’re essentially waterfall even though we use scrum terminology, there are some things managers just can’t live without!

If I had it my way, if I had developers working under me, I would see my role as essentially a buffer. I would be as much of a dev as I could manage but the difference would be that I would also buffer my devs from unnecessary meetings from higher up. I would be the one to gather information from external groups and filter down what is imporant to whom. I would gather my knowledge of their progress by asking them in person, one at a time, and being active in the daily process of work items. I would encourage them to communicate direction and continually with each other rather than setup a mandatory scrum meeting. To me scrum is like a “spray and pray” information dispersal method. It’s a waste of time for most people in the room every time someone else is speaking. I would encourage pair programming and I would be the one, as much as possible to maintain the database of work items and keep the devs pipelines full.

Also, integration sprints? Waste of time, continuous integration should fix that. Planning sprints? The dev lead should be continuously doing that. At some point bugs end up at the top of the developers pipelines simply because of their importance and therefore you are continuously fixing them rather than dedicating some period of time to bugs and other to features. In fact the whole idea of a sprint seems arbitrary to me. Just always be working on what’s next. At each step, with each feature your application should be working. Bugs simply coming to the top of the pipeline is basically equivalent to an integration sprint in my mind.

Code reviews? I despise gated commits. Code reviews should be done post commit. The dev manager should just look at the list of commits and start reviewing them. Peers shouldn’t really need to do formal code reviews because they should be in constant communication with people who they are working closely with. If there is a smell in something that was committed then start a discussion, no reason it couldn’t be fixed post commit. I’m assuming we’re using good source control tools that allow us to merge and branch confidently.

I could go on and on but I’m still working out these ideas, I have never really said these thoughts out loud before, except perhaps over a pint of beer with a friend.

The COLM Programming Language

http://www.complang.org/colm/

My mind is reeling from this link. Read the Ph.D. Thesis if you can, it’s got a very detailed description of parsing techniques and also outlines COLM pretty thoroughly. COLM shares a LOT of things in common with MetaSharp. There are enough differences that I’m not too worried but lots of great ideas in here.

The primary difference which, I’m now jealous of, is that in COLM the patterns appear to be more like objects, while in MetaSharp they appear to be more like functions. You can declare matches and treat them inside of expressions and statements as variables and perform match operators on them inline. Very cool. I think that I could actually do something like that too… maybe construct a Type that holds the function and also a function? I’ll have to think about it. Also, the patterns have variables associated with them, which is something I was thinking about doing too. Except I was going to create a let statement but this is different still somehow, it’s like they are simultaneously patterns and nodes, that’s an interesting idea. Also while reading this I can see that my notion of the “PatternContext” that gets passed aroudn is probably useless. I think that I can totally just create local variables that get passed into the constructor instead. That would be so much cleaner. I can see that is how they are doing the symbol table also.

Also, I don’t think that you need to formally make a lex and token types. I think those are just normal patterns and matches. It gets very esoteric in a lot of places also, a lot of implicit variables and some functions I’m not sure where they’re coming from, seemingly random empty brackets [] peppered around. But I’m really glad to see that my idea of putting arbitrary statements in productions is not totally crazy.

Tons to think about now!

ints by reference in C#

I wasn’t sure about this but I find this interesting:

object x = 7;
object y = 7;

Console.WriteLine(object.ReferenceEquals(x, x));
Console.WriteLine(object.ReferenceEquals(x, y));

Which prints:

True
False

Of course this is because we’re assigning the ints to objects, so they become boxed. This could be very useful to me…

[EDIT]

This actually works well except for the case of strings. They are already reference types and apparently they are special cased in .net such that there is always only a single instance of a partictular string.