Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

• You're doing everything wrong (NSFW language). But are you really? Or are you just doing it different?
• Some free icons from GitHub.
• An infographic about new syntax in C# 6.0.
• Did I do this one already? Well I'll list it again, because I like it so much. A dress that contains all the most commons passwords on it.

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

• Part 2 of using PostSharp to implement Undo/Redo. You will not believe how easy it is.
• There's also a Part 3 of using PostSharp to implement Undo/Redo.
• And guess what, there's a Part 4 of using PostSharp to implement Undo/Redo.
• I submitted something from "Look Around You" to the Moviecode tumblr, and it's in BASIC.
• I've heard from multiple sources now that SVG icons are becoming a trend. Check out geomicons.
• In my web development class at Capital University, a guest lecturer (Jon Plante) asked the students to go through an exercise of trying to name the website after taking away all the text and graphics. Dedesign the Web is just like that.

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

• 2013 Stack Overflow User Survey. 10% of users are working remotely full-time. I don't think they asked the question last year, but if they did, my bet is that percentage has gone up.
• Samuel L. Jackson does not like it, but Dennis Nedry loves Jurassic Systems.
• Add Undo/Redo to your application with PostSharp, using the Recordable Pattern.
• A way to deal with the Android slide-out menu and screen rotation.

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

• Give Spritz a try. I was able to read surprisingly fast, and I also felt like I was concentrating more and therefore retaining more of what I was reading.
• C# Pad, a web-based C# REPL.
• REPL means "Read-eval-print loop", by the way.
• Check out what's new with JustMock, JustCode, and JustTrace from Telerik
• Interesting posts from Rob Conery on UnitOfWork and Jimmy Bogard on Query Objects

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

The principle of least surprise (sometimes known as the principle of least astonishment in more posh circles) is an axiom of design: typically UI design, but also software design. The idea is that some object, operation, device, etc, should be obvious and consistent with its name/appearance. A trivial example: a "left click" should be done by pushing the button farthest to the left on the mouse. To do otherwise would be quite surprising, and make for a bad experience. (That sounds shockingly simple, but it's just an example).

I was thinking about this when I was writing some validation code. I was thinking about a user selecting a U.S. State in a dropdown. On some forms, it's required for the user to select a State, on other forms it's optional.

I wrote a class to help me manage a list of States/Provinces like so:

Elsewhere, I wrote code to use the IsValidState method to check to see if the user, in fact, selected a valid state or not. The first time I did this, it was on a form where the field is required. So, if user doesn't select a state, then IsValidState wouldn't even get executed.

But, later on, I reused IsValidState on a form where the state field is optional. What happens when the state argument is null? A big fat exception, that's what. So, I changed the method:

Is that the correct decision? Or should IsValidState only be called when there's an actual value? I think I made the correct decision, because null isn't a State. Another decision that could be made is throwing an ArgumentException if the argument is null or empty. However, I don't think the correct decision was to leave the method the way it was.

So now let's enter the land of hypotheticals in order to think more about the principle of least surprise.

What if, instead of being a boolean function, IsValidState instead acted upon a StateArgs object being passed in (and its name was changed to ValidateState). Let's suppose there is some reason for this, and that part of the design is a given.  Suppose there's a Value string property with the State and an IsValid boolean property. (ASP.NET Validators, specifically CustomValidators, work like this: the validation method get an "args" object, and you can act upon it by manipulating args.IsValid). What would the correct behavior be then if args.Value is null? Clearly, args.IsValid shouldn't be set to true. So, should it be set to false, or should it just be left unchanged?

In this circumstance, ValidateState is probably one method call in a series of validation method calls (probably with some polymorphism involved with the parameter instead of a specific StateArgs class). So it seems like the least surprising thing to do would be to not make a decision (option A in the above source code). Since ValidateState does not return a value, it's not required to make a decision.