12 Dec 2019 @ 3:30 AM 

When a programming language introduces a new language feature, inevitably that feature will become central to a style debate; When to use it, when not to use it, good places to use it, bad places to use it; places where it makes code easy to read, places where it makes code hard to read, and so on. the var Keyword is definitely no exception.

So What Is it?

“well, I’ve never seen one before, no-one has, but I’m guessing it’s a White Hole” – Kryten

The var keyword was introduced in C# 3.0. It allows for what is known as implicit typing– this allows a type to be inferred from the context by the compiler. var something=expression results in the something type being defined based on the type of the result for expression.

One thing to not confuse var with is Dynamic Typing where the type of a variable can change as the program runs- a variable with a string in python could be storing a number later or even a class instance. the use of inferred typing doesn’t change the conventional rules, and the code compiles to the same code it would if the type was fully defined, so it’s nothing more than a syntax sugar that can be used to shorten longer code.

The debates regarding var typically center around arguments that, when misused, it can make code harder to read. Personally, I am of the mind that in the situations where it makes code harder to read, it is not var that is pathological, but rather it is exposing a symptom of another problem.

A common-ground is found amongst most "factions" of the debate in terms of simple variable declarations which initialize to a new instance:

can be replaced with:

It is where we come into many other cases that opinions tend to differ for example this:

This tends to be the sort of example of "bad code"- here, we don’t know what type "value" is without hovering over it. We might assume it is a Something class, for example, but it may not be.

This is where I disagree. The problem I’ve found is examples tend to be precisely like that- simple, one-line pieces of code demonstrating the "folly" of using var. But outside of code obfuscation contests, I don’t think there are examples of real-world programs that are only one line, and certainly not so short of one. Code lines exist with other code above and below them- they exist within a specific context- not just the surrounding code, but the containing class, the containing namespace- even the general design of the project as a whole, which can inform a reader of this information that people often argue is no longer present when using var- to say nothing of a meaningful variable name, which is often not present either.

As a specific example, let me rip out a var line from an existing project:

This would seem a prime example of var being misused. What is "ghosted"? Is it a "GhostDrop" class? or what? Well, as it happens, it is a Nomino. This would seem to be a counter-example. However, as I mentioned, the context in which the code exists informs readers familiar with the project – BASeTris, in this example- GhostDrop being the logic that duplicates and translates an active Nomino Group into another Nomino group to be the “Ghost Drop”.

Another consideration is that for all the claims of it being hard to read:

because you do not know the type of “foo”, it seems the same contrived argument could be made against the use of fields:

And properties:

and out variables:

Which is obviously not something that tends to follow from claims that var makes code more difficult to read. In my opinion, var is not different from those two examples. If code is not written in an informing way, you will need to look elsewhere. However if the code is written well, in the context of the project and the person reading it has some basic understanding of some of the core classes, types, and conventions of a project, than it doesn’t usually get in the way. It could cause trouble if a project is unfocused, has several classes that perform similar “verbs”, or simply has less-than-perfect variable, function, property, and class names.

Posted By: BC_Programming
Last Edit: 12 Dec 2019 @ 03:33 AM

EmailPermalinkComments (0)
Tags
Tags: , , , ,
Categories: C#, Programming
 29 Nov 2012 @ 3:01 PM 

One of the big reasons I’ve found myself preferring C# Over Java is that C# is about a million times easier to refactor. By this, I mean that often times you can make rather large changes to a codebase without changing very much other code. This is possible because C# has features such as Properties (which allow you to encapsulate logic on what appears to be a variable access), operator overloads, and casting overloads (though those sort of count towards the previous point). Java doesn’t have these features, so I’ve found changes to the core logic of a program can cause reverberations throughout the entire codebase as every piece of logic that referred to the previous structure is made to refer to the new stuff. If you suddenly decide that a field needs logic, you need to create an Accessor method for it, and then you need to change all the references to the aforementioned field. This is easiest to accomplish by renaming the original field name so your compiler errors point to where you used it and changing each of those. C#, in contrast, let’s you change a field into a Property with very little impact on the code within that codebase. it does, of course, have the effect of requiring any dependent assemblies be recompiled and naturally any reflection that uses the aforementioned field will need to instead look for a property, but it will require very little actual code changes.

In a Previous post I discussed and provided a class that allowed the relatively transparent replacement of core fields in a class definition with a generic type that made the in-memory representation of that type obfuscated. This allowed a lot of logic to be executed transparently from code that used to simply access the field. Naturally this did have performance implications, but the fact that it’s possible to make such class definitions and their uses transparent aside from changing the declaration is one of my favourite features of C#. Combine this with the fact that changing, modifying, and refactoring existing code comprises a large portion of our work as developers and you have a recipe for making those tasks far less of a chore.

.NET 4.0 added quite a number of helpful little classes that “wrap” another type. It’s a very useful capability of the language. Since they don’t usually meverage .NET 4.0 or 4.5 features, you can often backport the class functionality. Arguably the only reason they are even in the library now is because they became something of a fundamental class in numerous available libraries.

One of these such classes is the ThreadLocal<T> type (ThreadLocal(Of T) for VB.NET, naturally). The purpose of this is to have a variable who’s value is separate on different threads. This can be useful for any number of different reasons. .NET 4.0 adds this class to the System.Threading namespace. The functionality, of course, can be useful in previous Frameworks, so it can be necessary to reconstruct the class.

That is what I’ll be doing here. The ThreadLocal&ltT&gt type has a relatively simple interface; it implements IDisposable and contains only a few methods, so it’s ripe for duplication for use in previous framework versions for which the Base Class Library lacks it. I will call my implementation “ThreadVariable”, but it could simply be called ThreadLocal instead, allowing code written using the variable for use in the BCL to work in previous framework versions (other framework differences notwithstanding, of course).

Posted By: BC_Programming
Last Edit: 29 Nov 2012 @ 03:02 PM

EmailPermalinkComments Off on System.Threading.ThreadLocal equivalent for .NET 2.0 and 3.5
Tags

 Last 50 Posts
 Back
Change Theme...
  • Users » 47469
  • Posts/Pages » 397
  • Comments » 105

PP



    No Child Pages.

Windows optimization tips



    No Child Pages.

Soft. Picks



    No Child Pages.

VS Fixes



    No Child Pages.

PC Build 1: “FASTLORD”



    No Child Pages.