| William's profileSo long, and thanks for ...BlogLists |  Tools  Help |
So long, and thanks for all the chips |
||||||
|
May 08 Hey, Twitter! I’m over here!OK, I need to stop being negative on my blog, but this rant has to be posted publicly. Twitter is a very useful service, and there’s a lot of new services popping up around it. Most of these new services actually rely on Twitter Search, though, and that’s where I’m in trouble. See, I’m invisible to Twitter Search. I’ve been using Twitter for nearly a year, but none of my Tweets appear. Makes it impossible to use hashtags, participate in Twibes and other things. I first noticed the issue a few months back when I tried to start using a #wpfonyx hashtag when tweeting about my Onyx project. The hashtag wasn’t working properly, and it took me a while doing some research to figure out the problem was that I simply was invisible to Twitter Search. On March 30, I opened a support request (Request 118748) explaining the issue. On April 1, @crystal closed the ticket with the following remarks.
Please note, this was a full closure of the ticket, which meant it was dead. Nothing I could do with this ticket after that. Also note that it was closed without a resolution. The link given doesn’t lead you to a posting which can be used to resolve the issue myself, but rather just takes you to a posting saying “yeah, we’re broke, nothing you can do, but hey, maybe you’d like to put a comment on this page to let us know you’re broken?” I thought this was horrid tech support. No company I’ve worked with would ever treat a tech support ticket in this fashion. What it comes down to is, they have a widespread problem, and don’t want to be burdened with having to track hundreds (thousands?) of tickets for the same issue. Their solution is this public forum posting. That’s a non-solution. From the customer’s end, there’s no longer any accountability. There’s no way for me to track the progress of the issue. So I put my comment on the page like they asked (which I did, more than once), and then what? They aren’t going to tell me when my problem is resolved. Theoretically I can get e-mailed with updates to this page, which I am doing, but that’s more than suboptimal. I now get spammed with nearly 30 updates a day, as more and more people add comments about how it’s broken, or still broken, for them. Worse, though, not only am I not able to track things, but Twitter Support isn’t either. They made some correction that evidently helped some folks out last month, but it didn’t correct the problem for everyone. There was no way for them to know that, however, unless people added new comments to this page. Now Twitter Support has the same problems with tracking that I do, but compounded because of the likely failure to track by the users. On April 21, I got fed up with this and opened a new request, Request 196806.
This request was promptly marked as resolved (don’t know the exact terminology that Twitter Support uses here, but this is the state that should have been used with the first ticket, as it allows me to reopen the issue if I don’t believe it is resolved). The history on the ticket doesn’t show me the full history (yet one more thing they should fix), it only shows me the comments that I added. So I can’t reveal exactly what they said, but there’s enough in my response when I reopened it to give you an idea.
Yeah, I know, I was a jerk here, and I’m showing my dirty laundry to the world. However, I think I was justified in being a jerk, since I was being jerked around by them. I understand Twitter is a free service for me, but that’s no excuse for acting so unprofessionally here. Heck, they couldn’t even be bothered to read the ticket, as the majority of their response had already been explicitly addressed. So, in my humble opinion, Twitter Support needs a major overhaul. However, the problem isn’t just Twitter Support. Obviously Twitter Development has some major problems as well. They have a known issue that’s impacting a very large number of users. It’s a fairly serious issue, and not just a minor inconvenience. This should be high priority. In addition, as a developer myself, it seems to be a problem that shouldn’t be that hard to diagnose and correct, and if it is, that would just speak volumes about the codebase. Yet, here I, and many others, are… invisible. This seems to be nearly as big of an issue as the stability problems Twitter suffered a while back. Update: On 5/13, Twitter shut down the forum page, claiming the problem was fixed. They also closed my support ticket. I was skeptical that the "fix" would apply to my own issue, and tweeted about it yesterday (along with several other tweets). Today, I'm still invisible to search. So, my skepticism was well founded. They closed the ticket assuming the problems were the same, without testing, despite the fact I explicitly stated it was unlikely the issues were related. I've reopened the ticket, but I'm not holding my breath on this one. May 05 WPF Model-View-ViewModel Toolkit 0.1In case you’ve missed the announcement, Microsoft has released a new toolkit as part of the WPF Futures which is meant to aid in the development of WPF applications that follow the M-V-VM (hence forth, I’ll call this View Model) pattern. Here’s my impressions of what was released. First, I’ll look at the Word documents included. There’s two parts to this. Part 1 provides a general introduction to the pattern. The first section of this document discusses the “Model-View-X Paradigm”. Eek. That rankles with me. Sorry, I’m nit-picking here, but this is meant as constructive criticism. Why Paradigm, instead of Pattern, which is the accepted word to use? In any case, this section seems to struggle a bit with describing what differentiates View Model from the other patterns, including a reference to Presentation Model with little explanation to why there’s a mention (such as, they’re the same pattern, perhaps?). I think this just lends further proof that we either should be able to communicate the differences, or we should stick with a single name for the pattern. The rest of this document tries to justify the pattern with a sample application, but I think the justification is poorly presented. The problem is that they work backwards, starting with a spaghetti implementation, refining it a bit and trying to explain why it’s better. I think it would work better to state why one would use the pattern up front, and then demonstrate the differences in an implementation. As it is, trying to figure out why requires reading the entire document. I’ll also note that the current structuring required putting the unit testing last, which many TDD and BDD practitioners will take issue with. When unit testing is such an important reason for why you’d use this pattern, I really think this is a mistake. I’ll also note that the section on commanding could use some work. There’s little explanation as to why RoutedCommands are problematic, and the one reason given isn’t even valid (the target of a RoutedCommand must be part of the UI element tree… which is disproved by the Onyx command binding services that easily create command bindings for RoutedCommands with the ViewModel as the target). Part 2 provides a walkthrough of writing a contact book application following View Model pattern. The overview describes the roles of the three components: Model, View and ViewModel. I’ll take exception to the description of the ViewModel, which explicitly states the ViewModel should not be aware of the View. That’s not really a requirement of the pattern, and in fact, while you should avoid tight coupling as always, some knowledge of the View is often beneficial if not necessary. I don’t mind code/frameworks that are opinionated on this topic, but this isn’t a framework, and I’m not sure that Microsoft should be in the business of being opinionated on topics like this. When you run the project template, it creates a project with four folders: Commands, Models, ViewModels and Views. I’m not sure how I feel about that. I will say that I’ve never used a folder structure like this. My Models are nearly always in a separate project. I prefer my ViewModels to live right along side the Views, as it makes it easier to find and open these related components. Finally, my Commands are usually defined in the ViewModels and not in separate classes, much less folders. This structure is typical in a web MVC architecture, but this isn’t MVC and I just don’t think I like this layout. The template imperatively creates the View and the ViewModel and associates them in code. I don’t care for this at all, much preferring a declarative approach using the XAML markup. The association is also solely through the DataContext, which is fine, but I prefer to use a different DP (which usually sets the DataContext as well). Within a View, the DataContext will change frequently (for instance, in ItemsControls), but I still want to be able to talk about the ViewModel associated with the child elements. The template creates a DelegateCommand class with a good implementation. One sincerely hopes this is a stop gap solution, as DelegateCommand really should reside in a library (preferably the BCL) and not be generated by the template. In any event, the DelegateCommand is certainly a best practice, and appears to be the only such concept actually included here, which is strange. Where’s the ViewModel base? Where’s the helpers for validation, INotifyPropertyChanged, etc. I realize this isn’t a framework, but there should still be more support from the templates. How about a ViewModel item template that creates a class that implements INPC? One hopes that version 0.2 starts to address the low hanging fruit here. The section on unit testing is going to be controversial. Not only did we not follow TDD/BDD as I pointed out earlier, but the walkthrough utilizes the “Create Unit Tests…” feature, which is a questionable practice even if you’re not going to follow “test first”. The “ClearContactBookCommandTest()” is long and complicated with a total of 6 asserts spread out through the entire test. Definitely not unit testing best practice here. What’s really heart breaking is that there’s even three sections of asserts with comments that read “// Validate something”. Isn’t that a clear indication that they should be separate tests? I hope future releases do a better job of promoting best practices here. The Toolkit is probably useful to some, though I won’t be using it, and I can’t point someone new to View Model at this as a learning point. May 04 A Rose by any other nameOK, it’s official. The WPF community loves the Model-View-ViewModel pattern. That’s wonderful! However, I have always had problems with the name. So much so, that I’ve frequently jokingly used the good Dr.’s MVPoo name instead. So, what’s wrong with the name? As the good Doc explains, there’s a lot of variations on what’s basically the same pattern (forgive me for taking liberties here, as I do know that the variations have very important qualities that distinguish them as unique patterns in and of themselves, but once distilled down for the layman, they’re just different shades of red). Adding a new variation on the pattern can be confusing enough that one should endeavor to ensure there’s no duplication, and let’s be honest, Presentation Model already exists. To be fair, as far as I can tell form searching the Internet on this topic, the first public exposure to Presentation Model was in May of 2004, while the first time Microsoft publicly used the M-V-VM name was in October of 2005. It seems reasonable to me that this variation on M-V-C may have been independently “discovered” at the same time, so it’s more than easy to forgive the existence of two names historically. However, I still find it to be very unfortunate that we have two names for the same pattern. In an ideal world, I would suggest we stick with a single name, and since Presentation Model was publicly first, we should go with Presentation Model. However, this isn’t an ideal world. The WPF community is too strongly entrenched with the M-V-VM name. The community is just not likely to give the name up, no matter what we do or say now. If it helps (and it helps me), you can think of M-V-VM as a variation of Presentation Model that’s specific to WPF and its data binding and commanding infrastructure. Unfortunately, for outsiders already familiar with Presentation Model, even this explanation is likely to cause confusion, but it’s better than no explanation at all. OK, so I’m admitting the name isn’t ideal because of the existence of two names for the same pattern, but I’m also relenting to the pressures of the community who have already adopted the name. However, even then, I have some other problems with the name. Model-View-ViewModel is a mouth full. It’s just too much to say and/or type. The acronym M-V-VM is less to type, but it still stinks. It’s a pain to type with the hyphens, and impossible to read without them. When spoken, it’s a tongue twister worthy of inclusion in the Fox in Socks book. I’ve heard from a few insiders that there’s a growing movement to correct this issue by renaming the pattern to just ViewModel (I assume they mean without the space, though I’d prefer View Model which is more in agreement with Presentation Model). This caused me to go over my angst about the name all over again. If we’re going to change the name, you’ll have to get the community to agree with the change. M-V-VM is so entrenched now, that I’m not sure it’s possible. However, if all of the more influential folks within the community were to adopt the change, it is possible that the community could be swayed. If we were to make that attempt, though, wouldn’t it be better to take the opportunity to reduce the name down to a single name? In other words, wouldn’t it be better to try and sway the community to switch to Presentation Model, which was publicly first and more widely known in the broader community? It seems so to me. However, one could argue that it’s more likely that we’d persuade the WPF community to change the name to View Model than to Presentation Model, because View Model is just a shorter way of saying the already entrenched Model-View-ViewModel name. So, what do others think? Should we try and change the name within the WPF community? If so, what name should we try and change it to: Presentation Model, View Model, ViewModel, MVPoo? Edit: Some discussion about this blog entry has also gone on in the WPF Disciples list here. May 01 yUML – Quite the interesting web serviceIsn't that diagram spiffy? OK, I’ll be the first to admit, there’s nothing that exciting about the image here. What I do find quite interesting is that it was dynamically created by a web service through the simple use of an <img> tag.
The text representation of the diagram can certainly be cryptic and complex, and you’d hardly want to use this for a very large UML diagram, but for blog posts where you want to highlight some design aspects, it can sure be a useful little tool. Check out some other samples using the tool. April 16 Behavior Driven Design and Specificity – Part III previously wrote about some ideas I was toying with for Specificity to add a base class to aid in writing BDD style test fixtures in a portable (works with any unit testing framework) fashion. I’ve been using a solution like I posted then ever since, and have concluded the design is a bit fragile. Relying on the actual test methods to properly use the Result property in order to ensure Arrange and Act are called, just isn’t a production quality design. That got me to thinking, however. What I was trying to do here was a poor man’s attempt at AOP (Aspect Oriented Programming). The .NET world already has a better (though not perfect) solution for AOP in the form of ContextBoundObject. I should be able to leverage that and get a much better implementation of the concepts I wanted. In fact, there’s a CodePlex project that uses this idea already, called MSTestExtensions. I didn’t care for the way you had to write extensions using MSTestExtensions, and it wasn’t going to work out of the box for my BDD base class in any event, so I had to just borrow the idea without using it. So, I spent a couple of days hacking, and the result is now in the Specificity project. I’m still not entirely convinced I’ve got the correct extension mechanism baked in, so if you start to use this code, beware that I’m very likely to make breaking changes in this area of the API. So, what did I come up with? First, there’s an ExtendableTestFixture base class that you inherit from if you want to be able to “extend” your test methods. This provides all of the ContextBoundObject magic, as well as provides the necessary hooks for you to be able to create TestExtensionAttribute attributes that actually modify the process flow of the test methods, allowing you to add code before or after the test method. The way you code a TestExtensionAttribute is where I’m most likely to make breaking changes. The BDD base class, called Observation in the previous post, is now called SpecificationContext. It inherits from TestExtensionBase and uses an internal SpecificationContextAttribute to cause all test methods to run the Arrange, Act and Teardown virtual methods. The use is the same as in the previous post (minus the Result property magic), but the implementation is now much more robust. There is a down side. ContextBoundObject adds some overhead to object creation and method calls that will slow your tests down. It’s my experience that the overhead isn’t all that great, and I’m more than willing to except it for the benefits provided here, but you’ll have to judge for yourself. There’s a couple of other test extension attributes included as well, just to illustrate that this is useful even if you’re not interested in using the SpecificationContext concept. There’s an ExpectedDurationAttribute which allows you to declaratively specify that a test shouldn’t take longer than some amount of time, and a TestTransactionAttribute that declaratively wraps your test method in a TransactionScope. I’ll admit, I’m not convinced attributes like these are appropriate… I’d prefer the non-declarative approaches, for many of the same reasons that I prefer Specify.That(action).ShouldThrow<Exception>() over ExpectedExceptionAttribute. However, I don’t want to force my opinions here on users, and I did need some attributes to illustrate what’s possible here. I’d love to hear feed back on this. March 20 Reflecting on CodeStatic reflection. It’s all the rage. What is static reflection? It’s obtaining type information at compile time instead of runtime, typically by using LINQ expression trees. Here’s my take on providing a static helper to do this. public static class Reflect { public static MemberInfo GetMember(Expression<Action> expression) { if (expression == null) { throw new ArgumentNullException( GetMember(() => expression).Name); } return GetMemberInfo(expression as LambdaExpression); } public static MemberInfo GetMember<T>(Expression<Func<T>> expression) { if (expression == null) { throw new ArgumentNullException( GetMember(() => expression).Name); } return GetMemberInfo(expression as LambdaExpression); } public static MethodInfo GetMethod(Expression<Action> expression) { MethodInfo method = GetMember(expression) as MethodInfo; if (method == null) { throw new ArgumentException( "Not a method call expression", GetMember(() => expression).Name); } return method; } public static PropertyInfo GetProperty<T>(Expression<Func<T>> expression) { PropertyInfo property = GetMember(expression) as PropertyInfo; if (property == null) { throw new ArgumentException( "Not a property expression", GetMember(() => expression).Name); } return property; } public static FieldInfo GetField<T>(Expression<Func<T>> expression) { FieldInfo field = GetMember(expression) as FieldInfo; if (field == null) { throw new ArgumentException( "Not a field expression", GetMember(() => expression).Name); } return field; } internal static MemberInfo GetMemberInfo(LambdaExpression lambda) { if (lambda == null) { throw new ArgumentNullException( GetMember(() => lambda).Name); } MemberExpression memberExpression = null; if (lambda.Body.NodeType == ExpressionType.Convert) { memberExpression = ((UnaryExpression)lambda.Body).Operand as MemberExpression; } else if (lambda.Body.NodeType == ExpressionType.MemberAccess) { memberExpression = lambda.Body as MemberExpression; } else if (lambda.Body.NodeType == ExpressionType.Call) { return ((MethodCallExpression)lambda.Body).Method; } if (memberExpression == null) { throw new ArgumentException( "Not a member access", GetMember(() => lambda).Name); } return memberExpression.Member; } } If you look closely, the code itself shows you a use for the idea. Yep, it’s definitely dogfood. Pay attention to how we raise ArgumentNullExceptions in this code. No “magic strings” for us. This is compiled code. If I use the wonderful IDE refactoring capabilities to rename the argument, the string passed to the ArgumentNullConstructor is also refactored, because it’s static code and not a string literal. There’s also situations where you don’t have an instance of data to use for reflecting, and the above code isn’t so useful in this case. That’s where it’s big brother comes in. public static class ReflectOn<T> { public static MemberInfo GetMember(Expression<Action<T>> expression) { if (expression == null) { throw new ArgumentNullException(Reflect.GetMember(() => expression).Name); } return Reflect.GetMemberInfo(expression as LambdaExpression); } public static MemberInfo GetMember<TResult>(Expression<Func<T, TResult>> expression) { if (expression == null) { throw new ArgumentNullException(Reflect.GetMember(() => expression).Name); } return Reflect.GetMemberInfo(expression as LambdaExpression); } public static MethodInfo GetMethod(Expression<Action<T>> expression) { MethodInfo method = GetMember(expression) as MethodInfo; if (method == null) { throw new ArgumentException( "Not a method call expression", Reflect.GetMember(() => expression).Name); } return method; } public static PropertyInfo GetProperty<TResult>(Expression<Func<T, TResult>> expression) { PropertyInfo property = GetMember(expression) as PropertyInfo; if (property == null) { throw new ArgumentException( "Not a property expression", Reflect.GetMember(() => expression).Name); } return property; } public static FieldInfo GetField<TResult>(Expression<Func<T, TResult>> expression) { FieldInfo field = GetMember(expression) as FieldInfo; if (field == null) { throw new ArgumentException( "Not a field expression", Reflect.GetMember(() => expression).Name); } return field; } } Now I can do something like this. class Program { public void Foo() { } static void Main(string[] args) { Console.WriteLine(ReflectOn<Program>.GetMethod(p => p.Foo()).Name); } } Want another, more practical use? public abstract class ObservableObject : INotifyPropertyChanged { public event PropertyChangedEventHandler PropertyChanged = delegate { }; protected void OnPropertyChanged() // All properties changed { OnPropertyChanged(null); } protected virtual void OnPropertyChanged(string propertyName) { PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } protected void OnPropertyChanged<T>(Expression<Func<T>> expression) { OnPropertyChanged(Reflect.GetProperty(expression).Name); } } public class Foo : ObservableObject { private string message; public string Message { get { return this.message; } set { this.message = value; OnPropertyChanged(() => Message); } } } No more magic strings when raising PropertyChanged from INotifyPropertyChanged implementations. The performance here is obviously worse than using the magic string, but it’s a lot better than using actual runtime reflection. March 17 Behavior Driven Design and SpecificityI’ve been using an assertion framework at least similar to the one I’ve put up on CodePlex called Specificity for quite some time now. The main goal of that library is solely to provide an assertion framework that’s extendable and discoverable, and it does so in a fashion that doesn’t tie it to any specific test framework. The naming conventions used within Specificity follow a more of the BDD form rather than the TDD form, with Should instead of Assert. However, I’ve not actually used any of the BDD frameworks available for .NET, mostly because I have to use MsTest at work and I am accustomed to using it and so continue to use it outside of work. Recently, I’ve been experimenting with following BDD at least to the extent that my unit testing framework of choice will allow (the Test terminology leaks through in the attribute names used, which BDD purists would not care for). This has eventually lead to me experimenting with a base class that I think may be useful for inclusion in Specificity. This base class isn’t tied to any testing framework, and thus could be a drop-in base class for tests you write using any existing testing framework, much like the assertions in Specificity. The base class is really quite simple, though I’m sure it could be expanded. Part of the inspiration came from Jean-Paul S. Boodhoo, though I’ve simplified it quite a bit in ways that most developers would be more comfortable with, I think. Here it is in all its glory (such as it is): public abstract class Observations<TResult> { private bool acted; private TResult result; protected TResult Result { get { if (!this.acted) { ArrangeAndAct(); } return this.result; } } protected virtual void Arrange() { } protected abstract TResult Act(); private void ArrangeAndAct() { Arrange(); this.result = Act(); this.acted = true; } } That’s it. I told you there wasn’t much to it. I’ve chosen to follow the AAA (Arrange, Act and Assert) terminology rather than the “context” and “because” terminology used by Jean-Paul, but the examples from the blog post of his that I linked are easily translated. Here’s his first example, just to give you the flavor of how this is used. [TestClass] public class When_adding_2_numbers : Observations<int> { protected override int Act() { return 2 + 2; } [TestMethod] public void should_result_in_the_sum_of_the_2_numbers() { Specify.That(this.Result).ShouldBeEqualTo(4); } } Of course, this was in MsTest, but you should be able to easily translate it to whatever test framework you use. I’ve not leveraged the Setup concepts available from most testing frameworks because it would tie the code to a specific testing framework, and because some frameworks (looking at you, xUnit.net) don’t have the concept, relying on the constructor instead. I’ve not addressed cleanup here, though it should be possible to work that one out. If your test methods are side effect free (they should be), there’s little purpose in enabling cleanup, so I’ve not bothered to think to deeply on that one. This seems extremely simplistic, but the point behind the base class is to force a BDD approach to testing, where you have a test per feature, rather than a test per class. It’s a poor man’s addition to a TDD framework to enable a BDD style. I’d love to hear input on this one. What do people think of the idea? What about the implementation? Should something like this go into Specificity? Nit-pick me to death, please. March 11 Onyx and SpecificityIn case you've not seen it other places, I've started a couple of CodePlex projects myself. The first is an assertion library for unit testing, with a focus on extensibility and intellisence discover ability, called . The second is a WPF framework to aid in the development of applications that use the M-V-VM design, called Onyx. Both are still under development and haven't yet had a release, but the code is usable and worth checking out. A Thriple PlayJosh Smith, a fellow Disciple who probably needs no introduction, has released a new project on CodePlex called Thriple. This project aids in the use of 3D concepts within WPF by providing simple concepts that do the heavy lifting for you: ContentControl3D which contains a BackContent as well, and can rotate to show both sides; and Panel3D which shows it's content along a single path in 3D space. This is definitely a project worth checking out if you want to add the final polish to your WPF applications, without having to learn the complicated 3D APIs. March 06 Dueling BanjosIn this case, the “banjos” are FXCop and StyleCop. Can’t we all just get along? Here’s the deal. I’m a big proponent of using static checkers such as FXCop and StyleCop. I think they go a long way towards improving the quality of code. However, lately there have been a few things about these tools that have been driving me crazy. Let’s start with FXCop. There’s a couple of warnings you run into frequently when developing in WPF (at least, I do). CA1810 is a warning about performance when you use a static constructor instead of a static initializer. My first though is, how bloody important is this sort of optimization? The hit can’t be that big, especially when you consider it’s a one time hit and not something that can be amplified by usage in a loop. This sounds like premature optimization to me, and we all know the famous quote about that! Normally, however, this would be a minor thing to comply with, and wouldn’t occur all that often. In fact, my natural instinct is to use an initializer. However, in WPF the static constructor is often required for things like registering class event handlers with the EventManager. You can’t really use an initializer for this, and suppressing this every time it happens is a PITA. At least with FXCop I can turn the rule off, even if I do have to manually do that for each and every project (hint Microsoft: we could use some sort of solution based configuration here). The next FXCop warning that’s annoying me a lot is CA1004, which complains when you use a generic type parameter only in the return type and not as a parameter type. Seems this is supposed to be “confusing” for developers. Well, I call BS. If you don’t understand how generics work, you probably shouldn’t be coding in .NET languages that support the concept. If you look around it’s really not uncommon at all to have code that uses a generic parameter as the return type, as syntactic sugar to simplify scenarios where you’d otherwise have to employ a cast. Again, though, I can turn this one off. StyleCop has a lot of rules I don’t agree with as well. The bloody file header stuff serves no real purpose, other than keeping specific legal counsel happy. Legally, you don’t have to provide a copyright statement at all: your code will still be protected by copyright laws. You certainly don’t have to repeat it for every file in a project. Not only does it clutter the source, it’s a PITA when the copyright notice must change (such as a change on the date). I also hate the warning that wants you to place the imports inside the namespace. VisualStudio doesn’t like this, either. The default templates put the imports outside, and intellisense helpers have a hard time with indentation for imports they add when inside the namespace. All for something that, despite the attempts to make it sound like a sound technical thing to do, it’s really just a “tabs vs. spaces” kind of debate. However, what I’m here to talk about today is how these two tools sometimes don’t like each other. The specific issue I want to talk about is with naming member variables. See, StyleCop doesn’t like you to use “warts” or “hungarian notation” at the beginning of member variable names. This means the typical usages of “m_” and “_” at the beginning of member variable names is verboten, according to StyleCop. OK, let’s not get into any “religious arguments” over this. I prefer the warts, honestly, but I can live without them. So, the warts are gone. I no longer use them, in order to keep StyleCop happy. Unfortunately, this means I often make FXCop unhappy. See, FXCop has this warning, CA1500, which complains when you use a local variable name that’s the same as a member variable name (thankfully, it doesn’t complain when you do this with parameters to constructors. However, it’s still fairly common to need a local representation of data for the same thing as the member. Argh!!! I’ve actually resorted to use names like “theWidget” instead of “widget” for local names, just to shut the tools up. This is a wart, but because it’s a word, StyleCop won’t complain. Sad. Very sad. I’d rather go back to using “m_” or “_” on member variable names (though “this._widget”, which another StyleCop rule requires, is a bit silly). Well, enough ranting. I’ve got work to do. |
|
|||||
|
|
