6 ms·

Simple but Interesting Features of VS2010 and C# 4.0

29 points by yread 15y ago

numlocked 15y ago
I think the only one of these that's innovative enough to be of interest to nonusers of C# + VS is the DataTips. It's basically a small watch window you can pin anywhere in the code, almost like a sticky note. You can pin any number of them, anywhere in the code, and they scroll around and are visible when viewing source & debugging. They remain in place between debugging sessions (presumably stored in the VS project file). Seems extremely useful. Definitely better than setting up and tearing down watch expressions all the time.
- mendicant 15y ago
  Yup. There's so many of these that are either irresponsible (Hiding code) or of limited usefulness (IsNullOrEmpty) or too limited to be truly useful (Named Parameters). Hiding Code: I've got an idea. If you've got to hide code, maybe it _doesn't belong in that class_. Single responsibility people. String.IsNullOrEmpty(): Wow! Thanks MS for saving me from writing one 4 line helper method. What would be useful is if you provided these helpers for the other 90 that I need every project. Seriously, any C# dev can provide you with their "utility" project that has them. Named Parameters & Defaults: Awesome!..... unless you need something other than a primitive, in which case you can't set default values, since it's nothing but a fancy compiler trick. I like C#, but really, there's not much they've added since Linq that's really crazy interesting. Not that there isn't, but most of it isn't listed in this article.
  - varunsrin 15y ago
    Hiding code is actually quite useful - its not meant to obscure code that doesn't belong, as you imply. Say for instance, I'm working on two methods that are expansive, but i'm trying to debug a small part of those methods. To make watching breakpoints and tracking flow easy I hide all but the necessary parts of the code. I use regions in pretty much the same way - once I have a certain region of functionality locked down and tested, I hide it so I can focus on the part that's still being developed / tested.
    - kevinkemp 15y ago
      If your method only has one responsibility, the chance that you need to "hide" any code is almost nonexistant.
      - jasonlotito 15y ago
        Of course, if your methods are properly written, the chance you need to "see" all the code is almost nonexistent.
    - mendicant 15y ago
      My point is: If your class/code/file is so big that you need to hide code to be able to easily navigate (or worse, understand) it, you're doing something wrong. I understand this is a religious argument of the code world and you're likely to disagree with me. I'm fine with that.
      - boyter 15y ago
        You are missing the point. Lots of large applications I work on maintaining have large awful methods. This feature is excellent in these cases. You could argue that I should re-factor the whole thing to avoid this issue, but certain design decisions made by someone else make this a huge change, and in the world of risk adverse enterprise applications that is not going to happen.
        hkarthik 15y ago
        Can you not start writing tests against those monster methods so that you've got a refactoring safety net? I totally agree on being practical and not refactoring methods that work correctly. But if you find yourself in the monster methods making changes quite often, it seems irresponsible to not refactor and leave the camp ground cleaner for the next time you or someone else comes through it.
        boyter 15y ago
        Its a big ball of dependencies with no chance to mock due to someone deciding on being "clever". Its up there with being untestable. Generally I agree. If possible clean it up, but quite often its a small one line change, which needs to be fixed ASAP, so there is little chance to refactor.
  - kevinkemp 15y ago
    I wouldn't lump named parameters and defaults together like that. They're completely separate concepts.
    - mendicant 15y ago
      true, but they kind of go hand in hand. The nice part about named params is that it can make your code more clear if you have a lot of parameters on a method... but you could do the same thing by introducing a parameter object and be as clear and more resistant to change.
- mattmanser 15y ago
  Yeah, 3.5 was where all the c# innovations were, .net 4 seems to have been all about the DLR. VS wise the power tools have some fun features, auto brace completion and auto semi-colon insertion when you do shift-enter from anywhere on the line.
aforty 15y ago
A few of those features are ones that VB.NET developers have long been enjoying and yet VB.NET is still looked down upon when functionally it and C# have been equal for years. Yes I'm a little bitter because I had to learn the disgustingly ugly syntax that is C# when I recently switched jobs.
- artmageddon 15y ago
  If you ever need to do C++ or Java at some point, you'll have a much easier transition to those from C# than you would with VB.Net. I started with the VB 5 first in high school, then C++ & Java, and now C# where I am now.
- nopassrecover 15y ago
  The "ugly" c-style C# syntax is far more expressive. Using VB.NET feels like using crayons to draw portraits.
kogir 15y ago
Beware default values. They're set at the point of invocation at compile time. This isn't a problem, but you need to be aware of it. For this reason it's considered bad form to publicly use default values library assemblies - the callers won't see any change until they too are recompiled. See http://blogs.msdn.com/b/ericlippert/archive/2011/05/19/optional-argument-corner-cases-part-four.aspx http://blogs.msdn.com/b/ericlippert/archive/2011/05/19/optio...
- xpaulbettsx 15y ago
  Interesting, didn't know that - good tip
- photon137 15y ago
  Isn't that a standard feature of x86 function-invocation, ie, argument values are stored in caller's stack? (although C# runs on CLR, but still...)

29 points by yread 15y ago

I think the only one of these that's innovative enough to be of interest to nonusers of C# + VS is the DataTips. It's basically a small watch window you can pin anywhere in the code, almost like a sticky note. You can pin any number of them, anywhere in the code, and they scroll around and are visible when viewing source & debugging. They remain in place between debugging sessions (presumably stored in the VS project file). Seems extremely useful. Definitely better than setting up and tearing down watch expressions all the time.

mendicant 15y ago
Yup. There's so many of these that are either irresponsible (Hiding code) or of limited usefulness (IsNullOrEmpty) or too limited to be truly useful (Named Parameters). Hiding Code: I've got an idea. If you've got to hide code, maybe it _doesn't belong in that class_. Single responsibility people. String.IsNullOrEmpty(): Wow! Thanks MS for saving me from writing one 4 line helper method. What would be useful is if you provided these helpers for the other 90 that I need every project. Seriously, any C# dev can provide you with their "utility" project that has them. Named Parameters & Defaults: Awesome!..... unless you need something other than a primitive, in which case you can't set default values, since it's nothing but a fancy compiler trick. I like C#, but really, there's not much they've added since Linq that's really crazy interesting. Not that there isn't, but most of it isn't listed in this article.
- varunsrin 15y ago
  Hiding code is actually quite useful - its not meant to obscure code that doesn't belong, as you imply. Say for instance, I'm working on two methods that are expansive, but i'm trying to debug a small part of those methods. To make watching breakpoints and tracking flow easy I hide all but the necessary parts of the code. I use regions in pretty much the same way - once I have a certain region of functionality locked down and tested, I hide it so I can focus on the part that's still being developed / tested.
  - kevinkemp 15y ago
    If your method only has one responsibility, the chance that you need to "hide" any code is almost nonexistant.
    - jasonlotito 15y ago
      Of course, if your methods are properly written, the chance you need to "see" all the code is almost nonexistent.
  - mendicant 15y ago
    My point is: If your class/code/file is so big that you need to hide code to be able to easily navigate (or worse, understand) it, you're doing something wrong. I understand this is a religious argument of the code world and you're likely to disagree with me. I'm fine with that.
    - boyter 15y ago
      You are missing the point. Lots of large applications I work on maintaining have large awful methods. This feature is excellent in these cases. You could argue that I should re-factor the whole thing to avoid this issue, but certain design decisions made by someone else make this a huge change, and in the world of risk adverse enterprise applications that is not going to happen.
      - hkarthik 15y ago
        Can you not start writing tests against those monster methods so that you've got a refactoring safety net? I totally agree on being practical and not refactoring methods that work correctly. But if you find yourself in the monster methods making changes quite often, it seems irresponsible to not refactor and leave the camp ground cleaner for the next time you or someone else comes through it.
        boyter 15y ago
        Its a big ball of dependencies with no chance to mock due to someone deciding on being "clever". Its up there with being untestable. Generally I agree. If possible clean it up, but quite often its a small one line change, which needs to be fixed ASAP, so there is little chance to refactor.
- kevinkemp 15y ago
  I wouldn't lump named parameters and defaults together like that. They're completely separate concepts.
  - mendicant 15y ago
    true, but they kind of go hand in hand. The nice part about named params is that it can make your code more clear if you have a lot of parameters on a method... but you could do the same thing by introducing a parameter object and be as clear and more resistant to change.
mattmanser 15y ago
Yeah, 3.5 was where all the c# innovations were, .net 4 seems to have been all about the DLR. VS wise the power tools have some fun features, auto brace completion and auto semi-colon insertion when you do shift-enter from anywhere on the line.

aforty 15y ago

A few of those features are ones that VB.NET developers have long been enjoying and yet VB.NET is still looked down upon when functionally it and C# have been equal for years. Yes I'm a little bitter because I had to learn the disgustingly ugly syntax that is C# when I recently switched jobs.

artmageddon 15y ago
If you ever need to do C++ or Java at some point, you'll have a much easier transition to those from C# than you would with VB.Net. I started with the VB 5 first in high school, then C++ & Java, and now C# where I am now.
nopassrecover 15y ago
The "ugly" c-style C# syntax is far more expressive. Using VB.NET feels like using crayons to draw portraits.

kogir 15y ago

Beware default values. They're set at the point of invocation at compile time. This isn't a problem, but you need to be aware of it. For this reason it's considered bad form to publicly use default values library assemblies - the callers won't see any change until they too are recompiled. See http://blogs.msdn.com/b/ericlippert/archive/2011/05/19/optional-argument-corner-cases-part-four.aspx http://blogs.msdn.com/b/ericlippert/archive/2011/05/19/optio...

xpaulbettsx 15y ago
Interesting, didn't know that - good tip
photon137 15y ago
Isn't that a standard feature of x86 function-invocation, ie, argument values are stored in caller's stack? (although C# runs on CLR, but still...)