The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

RobertoI (29) [Avatar] Offline
Across the various listings I have noticed an overuse of "var", which makes code a bit less readable and obvious than if variables were declared explicitly, especially in the case of primitive types such as int and string.
matthew.groves (46) [Avatar] Offline
Re: Coding style
Can you name some specific listings where it's a problem? I do tend to use 'var' a lot, but I realize that some developers don't like 'var'.
RobertoI (29) [Avatar] Offline
Re: Coding style
It was actually a general comment on the use of var, because I am one of those developers not particularly keen on it. But I understand you might have a different view on it smilie
matthew.groves (46) [Avatar] Offline
Re: Coding style
My personal view and style is that 'var' makes my code less repetitive; I tend to use it always. For instance, I hate seeing this sort of thing:

Repository repository = new Repository();

I'm communicating that the variable is a repository three times in one line!

But, I agree that use of 'var' can sometimes not be clear, especially if I've named the variable badly, or the right side of the assignment is complex. If that's the case for certain examples in my book, I'll be happy to take a second look and replace 'var' if necessary.

Another consideration is that the width of a page is limited (even in eBooks), so sometimes the use of 'var' makes it possible for me to fit more code into a single line. But again, if there are specific examples where 'var' is a hindrance, I would prefer the code was clear over the code being concise. I would appreciate you pointing them out so I can take a second look.
sbohlen (3) [Avatar] Offline
Re: Coding style
IMO its a misapplication of 'var' to consider it a 'data-entry shortcut' so as to avoid typing more characters. Using 'var' is neither 'good' nor 'evil', but using it (or not) should be done with an awareness of the level of contract one is stating to the compiler by its use. 'Var' declarations are a stellar example of a language feature added to support a very narrow use-case (see: LINQ of course) that carry significant side-effects when used beyond their intended use-case (some side-effects positive, others maybe not so much if unaware of them).

Using 'var' says to the reader of the code (and of course to the compiler as well) "I don't actually care what type is returned from the RH side of the assignment statement, just make sure that whatever it is has a public API 'surface area' that satisfies the rest of the places this variable is interacted with by my code."

For example, the following three declarations are in fact saying something QUITE different (to both the reader and the compiler):

var repository = GetRepository(); //line #1
IRepository repository = GetRepository(); //line #2
Repository repository = GetRepository(); //line #3

The first line says "gimme an object that has a shape that satisfies everywhere else I used this variable in scope". It *might* be a Repository instance, but it might just as well be something else. The compiler only complains if somewhere else in scope you say repository.Save() but your instance lacks the .Save() method (for example). *ANYTHING* with a .Save() method might be returned from the GetRepository() method ... you have no way to enforce WHAT it is and so this represents a pretty loose 'contract' that's being enforced. Sometimes this is actually what one really wants, but its a very different intent that's being communicated when comparing #1 to either #2 or #3.

Line #2 says "I don't care what concrete object is returned from GetRepository(), but I am saying that what controls the 'shape' of what satisfies this contract will be the declaration of the IRepository interface (elsewhere) and independent of the way that object might be used in the rest of my code which interacts with this variable instance". Whether or not .Save() is ever called on the instance returned from GetRepository(), if there is a .Save() on the IRepository interface then there better be a .Save() on the instance. This is (conceptually) a tighter contract to enforce than that of line #1 but still looser than that of line #3.

Line #3 of course says "only an instance of Repository itself will satisfy this contract", probably the strictest contract one could state (certainly the strictest of the three).

These three declarations all have their place in code (and their pros and cons) but since they all represent *very* different statements of intent, I'd guard against using decision factors like "... if I've named the variable badly, or the right side of the assignment is complex." b/c that tends to subvert your intent. Bottom line: 'var' should be restricted to those places where (for good design reasons) you want/need to loosen the type-safety of the contract the compiler can be made to enforce for you.

FWIW, I think the ctor example (often used) is somewhat of a red-herring since the compiler will enforce that "new Repository()" can *only* return a concrete instance of Repository so "var repo = new Repository();" isn't *actually* any looser type-safety than the longer (and needlessly verbose) "Repository repo = new Repository();" version smilie

Just my two-cents (ok, probably more like $1.50, but I went off the rails after the first paragraph) <g>