views:

643

answers:

10

I like C# 3.0 features especially lambda expressions, auto implemented properties or in suitable cases also implicitly typed local variables (var keyword), but when my boss revealed that I am using them, he asked me not to use any C# 3.0 features in work. I was told that these features are not standard and confusing for most developers and its usefulness is doubtful. I was restricted to use only C# 2.0 features and he is also considering forbidding anonymous methods.

Since we are targeting .NET Framework 3.5, I cannot see any reason for these restrictions. In my opinion, maybe the only disadvantage is that my few co-workers and the boss (also a programmer) would have to learn some basics of C# 3.0 which should not be difficult. What do you think about it? Is my boss right and am I missing something? Are there any good reasons for such a restriction in a development company where C# is a main programming language?

Thank you very much for you opinion!

+10  A: 

I have had a similar experience (asked not to use Generics, because the may be confusing to my colleagues).

The fact is, that we now use generics and non of my colleagues are having a problem with them. They may not have grasped how to create generic classes, but they sure do understand how to use them.

My opinion on that is that any developer can learn how to use these language features. They may seem advanced at first but as people get used to them the shock of newness lessens.

The main argument for using these features (or any new language features) is that this is a simple and easy way to help my colleagues advance their skills, rather than stagnating.

As for your particular problem - not using lambdas. Lots of the updates to the BCL have overloads that take delegates as parameters - these are in many cases most easily expressed as lambdas, not using them this way is ignoring some of the new and updated uses of the BCL.

In regards to the issues with your peers not being able to learn lambdas - I found that Jon Skeets C# in depth deals with how they evolved from delegates in a manner that was easy to follow and real eye opener. I would recommend you get a copy for your boss and colleagues.

Oded
Lately I've been discussing about how to do stuff in C#, and because of my more advanced knowledge of C# 3 features, I could translate many *paradigms* and patterns from other languages to C#, while the others kept bragging about how static and bad C# was. This made me realize you have to really know something before you complain. This also made me realize that when you know a language more than well, programming in it is way easier.
Dykam
Sadly, "any developer worth their salt".. isn't useful at all to a middle manager in a corporation trying to make do with the rather weak people he has. I wouldn't want to work there, but I understand the problem. Maybe you don't realize how hard it is in that environment to actually fire crappy programmers and get good ones.
darron
I do realize this... and I realize I have more talent than others. But this doesn't mean you should keep away from new language features, and you can make learning them a requirement.
Dykam
I second the suggestion of getting a copy of C# in Depth for your boss and each of your colleagues. It might not be a bad idea to have some spare copies around too, just in case. You never know when you'll need a copy in an emergency.
Jon Skeet
@Jon Skeet: Of Course you do, it's your book! ;)
RCIX
+2  A: 

Like it or not, if you plan on using LINQ in any situation, you're going to have to utilize some of the C# 3.0 language specs.

Your boss is going to have to warm up to them if he wants to utilize the feature sets you get from 3.5, which are numerous and worth your time investing in.

Also, from my experience in leading teams, I've found that using the 3.0 specs actually has helped devs readability and understanding of the code base. There's about a weeks worth of time that is spent by the dev trying to understand what the syntax means, but once they get it they much prefer the new way over the old way.

Joseph
+3  A: 

If the project is strictly C# 3+ from now on, then you would not break the build by including these items. However, before using them you should be aware of the following:

  • You can't use them if the project lead gets to make the decision and votes no.
  • Other than that, you should use them where it makes the code significantly easier to maintain.
  • You should not use them in ways that are confusing, or unnecessary in the sense that they do not significantly improve the maintainability of the code. This does mean you should not use them where the code is effectively the same or barely improved.
280Z28
The problem is is that if use of features is confusing is partially subjective and greatly depends on how used you are to it.
Dykam
Maybe you can't use them if the project lead votes no, but such a project lead would be *wrong*.
Joel Mueller
+3  A: 

If Microsoft didn't define the standard and these were features that they added to a non-Microsoft language, I would say your boss might have a point. However, since Microsoft defines the language and uses these very features in implementing significant parts of .NET 3.5 (and 4.0), I'd say that you'd be foolish to ignore them. You may not choose to use some of them -- var, for instance, may not be acceptable in all environments due to coding standards -- but a blanket policy of avoiding new features seems unreasonable.

The trickier bit is when should you start using new features, because they can be confusing and may delay development. In general, I choose to use new language features and platform elements on new projects. I often avoid using them on projects that are currently in development when the feature/framework enhancement comes out, deferring until the next project. On a long project, I might introduce them at a significant milestone if the amount of rearchitecting is small or the feature is worth the changes. Normally, I'd wait until the project is due for significant changes anyway and then evaluate if refactoring to newer features is warranted.

tvanfosson
I would be hesitant to assume that a language feature was safe to use just because it came from the lab of MS. There is no guarantee that a feature won't turn out to be a bad idea down the road and such considerations should be given anytime a new language feature is utilized.
brian
With respect to framework enhancements, I would be apt to agree. With language features, less so. Any features/framework elements that you use need to pass the smell test -- is this good code? Framework elements need to also have some reasonable hope of a long life as well. Language features, typically, are much more stable and more conservatively introduced in my experience. Reading @Eric Lippert's blog (http://blogs.msdn.com/ericlippert/default.aspx) has been very informative in that respect.
tvanfosson
@user: I wouldn't assume it at all. I'd look at the fact that VS2008 has been out for a few years, and that VS2010 has been out in beta (with the new language features) for about six months. There's more than enough experience, world-wide, with the new features, to know whether or not Microsoft has laid an egg.
John Saunders
+3  A: 

The jury is still out on the long term consequences of some features, but if their main rationale is 'it is confusing to other developers' or something similar than I would be concerned about the quality of the talent.

brian
+7  A: 

You boss is going to need to understand that language (and other) improvements are designed to give developers more capabilities, and make them more efficient in completing the task at hand, and that if he is not going to allow them for unknown reasons then:

  • The development team isn't producing at its greatest potential.
  • The company isn't benefiting from increased efficiency/productivity.

like others have said developers aren't worth their salt if they can't keep up with some of the latest improvements in the language that they are using on a daily basis. I suspect your boss hasn't done much coding lately and it is his inability to understand the latest language improvements that has motivated this decision.

Jon Erickson
+2  A: 

Some people are just afraid of change, because maybe you'll make them all look stupid using fancy new technologies. Could also be that your boss doesn't want the team learning new things instead of getting work done the old fasioned way.

The var keyword can certainly be abused, but in most cases reduces redundant code. LINQ is the main thing you want from .Net 3.5 because of the huge time saving in the amount of code you have to write. Your boss should be encouraging you to use it. Also the base class libraries now take delegates are parameters, so you will be limiting yourself a lot by not using them. Lambda's are just some fancy syntactic sugar to make delegates cleaner.

I would refer you to Effectively Integrating into Software Development Teams and Leading by Example. Two really great articles on how to deal with teams that are afraid of change.

Ryu
+4  A: 

I was told that these features are not standard and confusing for most developers and its usefulness is doubtful. I was restricted to use only C# 2.0 features and he is also considering forbidding anonymous methods.

Presumably roughly translates to your boss meaning...

These features are confusing for me, and I don't find them useful because I don't understand them.

Which is fairly symptomatic of the Blub paradox (well, or just sheer laziness). Either way there's no merit in what he's saying, and you should start looking for another job if he continues down that road.

Greg Beech
+3  A: 

I like C# 3.0 features especially lambda expressions, auto implemented properties or in suitable cases also implicitly typed local variables (var keyword), but when my boss revealed that I am using them, he asked me not to use any C# 3.0 features in work. I was told that these features are not standard and confusing for most developers and its usefulness is doubtful.

He's got a point.

Following that line of thought, let's make a rule against generic collections since List<T> doesn't make any sense (angle brackets? wtf?).

While we're at it, let's eliminate all interfaces (when are you ever gonna need a class without any implementation?).

Hell, let's go ahead eliminate inheritance since its so tricky these days (is-a? has-a? can't we all just be friends?).

And use of recursion is grounds for dismissal (Foo() invokes Foo()? Surely you must be joking!).

Errrm... back to reality.

Its not that C# 3.0 features are confusion to programmers, its that the features are confusing to your boss. He's familiar with one technology and stubbornly refuses to part with it. You're about to enter the Twilight Zone Blub Paradox:

Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.

C# 3.0 isn't hard. Sure you can abuse it, but it isn't hard or confusing to any programmer with more than week of C# 3.0 experience. Your boss's skills have just fallen behind and he wants to bring the rest of the team down to his level. DON'T LET HIM!

Continue using anonymous funcs, the var keyword, auto-properties, and what have you to your hearts content. You won't lose your job over it. If he gets pissy about it, laugh it off.

Juliet
Well you could lose your job over it... but is this case I'm not sure that would ba a bad thing.
Matthew Whited
+1 for the Blub paradox, it's so true !
Thomas Levesque
+2  A: 

Perhaps you can do a presentation once a week on each feature to everyone and get some of the developers on your side to help convince management of the benefits.

I recently moved from a bleeding edge C# house to a C# house that was running mostly on dot.Net 1.1 and some 2.0 projects, using mostly only 1.1 features. Luckily management stay away from the code. Most of the developers love all the new features in the newer frameworks, they just don't have the time or inclination to figure them out by themselves. Once I managed to show them how they can make their own lives easier they started using them by themselves and we have migrated several projects to gain the new language features and better tool advantages.

feihtthief