Michael Flanakin's Web Log

Comments and complaints on software and technology in general

  Home  |   Contact  |   Syndication    |   Login
  159 Posts | 18 Stories | 268 Comments | 497 Trackbacks

News

This weblog is no longer being maintained. For the latest, check out www.michaelflanakin.com!

Twitter












Tag Cloud


Article Categories

Archives

Post Categories

Image Galleries

Miscellaneous

Here's a list of features that I'd like to see in VS. I'm grouping them by version to show if/when they are ever handled.

2005

  1. Support for More UML Diagrams
    Team System currently only supports the class diagram (with respect to UML). I'd like to see more support for UML-like diagrams. For instance, use case, activity, and sequence diagrams are the ones that I use the most - for every project. The use case and activity diagrams are generally used for requirements, but considering the lifecycle support goal of Team System, I think this would be a good thing.
     
  2. Auto-generation of Property Accessors
     
  3. Filter IntelliSense Members
     

2003

  1. Auto-generation of Property Accessors
    This could be implemented like the auto-generation of inherited abstract and interface members works now.
     
  2. Filter IntelliSense Members
     

2002

  1. Auto-generation of Property Accessors
    I use getters and setters consistently. And, when I do so, I use a small Excel spreadsheet that creates the private and public code (to include XML documentation). I just copy-paste from Excel to VS, and everything is laid out. Sometimes, I only add one property, tho, and it's not worth openning up Excel. So, what I propose, is an automatic property accessor generator. For instance, given the following code...
    private string _name;
    This would be autogenerated...
    /// </summary>
    /// Gets or sets the Name property.
    /// </summary>
    public string Name
    {
      get { return this._name; }
      set { this._name = value; }
    }
    Obviously, the summary is less than desirable, and you may want to make this a protected or read-only member, but that can all be done manually. Just writing this code is helpful. And, I'm sure the first thing you wanted to say was that you use different private member naming standards. Well, there would have to be an option to specify possible naming standards to use. And, if none are applied, the name, as-is, is used. For instance, the option could be setup as a format string like "_{0}". This would allow other popular choices like, "{0}" and "m_{0}" and even "_str{0}" or "m_str{0}". Hungarian notation might introduce a kink, but if you could specify more than one format to try out, then you should be fine for the most part. As I mentioned before, I'm only looking for an 80% solution.
     
  2. Filter IntelliSense Members
    There are times when I'm looking using IntelliSense and I want to limit what I see to a certain type of member (i.e. locals, fields, properties, methods, and events). There are a bunch of different types of objects to be sorted thru, so this even gets into interfaces, classes, and delegates. Beyond that, perhaps a modifier is how you want to filter (i.e. abstract, private, protected, internal, protected internal, public, static). I'd love to be able to filter that list of items by these criteria. That'd help when trying to figure out a new object's capabilities.
     

See Also

  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati
posted on Saturday, July 31, 2004 12:20 PM