Adopting standard libraries

Question

My team has a command parsing library for console apps. Each team around us has their own as well. There isn't anything in the BCL so I suppose this is natural.

I've looked at the the module in Mono, which seems solid, and the one on CodePlex looks fine as well. There are probably others out there that will work (and I would love to hear your suggestions).

The real question is: how do I get my team, and others around us, to commit to just using one?

Answer 1

Once you find a solution, you start forcing it in code reviews. If it's not implemented in new code, tell them, sorry, but you have to go back and do it again. If you already have standards and reviews in place, this is a lot easier to implement.

Answer 2

Well to be honest, you can't make everyone settle on one solution. You can suggest a solution and point out it's benefits, but eventually the advantages would have to be greater than the inertia that they have built up with their present library.

To make them settle on one library you would need to go up the management change until you get to the person that manages all the groups involved. Convince that person why everyone should use one library then let it filter back down.

Now that I have said that, why does it matter? Does your team routinely have to work on code from the other teams? Are the other teams using libraries that cause problems for your code? Is this standardization purely for the sake of standardization or is there some specific problem that not standardizing causes?

Answer 3

EBGreen, good point, I should have mentioned why I am looking to do this. Our teams frequently read and edit code from the surrounding teams. And I mean feature teams, not just dev/test/pm divisions.

This is just one of those little things that slow everybody down. Working on Team C's code? Got to track down their lib, which mysteriously isn't in the nightly builds (another problem, but independent of this). Reviewing another dev's work? Need to figure out how their parser works. Starting a new project? Need to decide which library to import.

I think that your response does indicate the solution though: Put the library somewhere very convenient, so it can be picked up by new projects (I doubt that many existing ones will be revised, nor should they be if they're working fine), and make the advantages of using it clear.

Thanks!

Answer 4

@fatcat1111, in that case by all means a standardized library would be advantageous. As for how to convince the other teams, there are two approaches that I can think of. First point out that standardization across a group always reduces coding effort (discounting for the initial ramp up for people that are new to the standardized library). Second, try to convince them on features. Hopefully you would be choosing the most feature complete library so it would be superior to what everyone else is using.

Answer 5

PowerShell provides great command line parsing options for free. When you create a cmdlet, you define properties and use attributes to determine command line options. The PowerShell runtime then handles the parsing of input for you.

Also, since PowerShell works with .NET objects, the result of your commands can be rich objects with properties and methods.

Here is a nice blog post demonstrating writing and debugging cmdlets.

Answer 6

I recommend NDesk.Options. It makes use of Lambda functions / .NET 3.5 and it's very nice:

http://www.ndesk.org/Options What you basically do is:

var p = new OptionSet () {
    { "file=",      v => data = v },<br>
    { "v|verbose",  v => { ++verbose } },<br>
    { "h|?|help",   v => help = v != null },<br>
};
List<string> extra = p.Parse (args);

And you're done.

It support key/value pairs with custom separators, lists, single value options and toggle options

You WILL NOT regret using it.