Forums
We just discussed ViewState last week, and that may have inspired Russell F to share with us this little snippet.
private ConcurrentQueue<AppointmentCuttOff> lstAppointmentCuttOff
{
get
{
object o = ViewState["lstAppointmentCuttOff"];
if (o == null)
return null;
else
return (ConcurrentQueue<AppointmentCuttOff>)o;
}
set
{
ViewState["lstAppointmentCuttOff"] = value;
}
}
This pattern is used for pretty much all of the ViewState data that this code interacts with, and if you look at the null check, you can see that it's unnecessary. Our code checks for a null, and if we have one… returns null. The entire get block could just be: return (ConcurrentQueue<AppointmentCuttOff>)ViewState["lstAppointmentCuttOff"]
The bigger glitch here is the data-type. While there are a queue of appointments, that queue is never accessed across threads, so there's no need for a threadsafe ConcurrentQueue.
But I really love the name of the variable we store in ViewState. We have Hungarian notation, which calls it a lst, which isn't technically correct, though it is iterable, so maybe that's what they meant, but if the point of Hungarian notation is to make the code more clear, this isn't helping.
But what I really love is that these are CuttOffs, which just sounds like some retail brand attempting to sell uncomfortably short denim. It'll be next year's summer trend, mark my words!