Once implicit/inferred typing is introduced, how can I impress upon students the importance of not abusing it? I typically have the same students two semesters in a row, for programming I (VB.NET) and programming II (C#). In our early, impressionable time together, I stress to these students (high-schoolers) and show them by example (I write lots of code for them) the importance of writing clear, readable code, which is partly achieved by explicitly specifying types for all variables (at first I do not tell them there are other options)

However, at some point, I have to reveal to my students that they can, indeed, declare a variable as an Object (i.e. Object x = new Horse("Silver");) and that it can hold anything; or, that they can declare a variable as var (i.e. var y = "foo";) and that the compiler will figure out what type it is. Some of them discover this on their own, of course.

Then I inevitably have students who abandon the good habits they had formed and want to make everything an Object, or declare everything as var (note I realize this is not equivalent in the language, but students tend to abuse the usage in the same way). I am always torn about how insistent to be that they revert, because I know the use of var in C# is controversial in the industry. (See the SO discussion use of var in C# for an example). Plus, the more savvy students are hanging out in SO anyway, and they see some questions and answers that lack explicit typing and other good programming habits.

My question is, since these students are still learning, and since it is my classroom after all, should I emphatically require that they always explicitly specify types unless absolutely necessary? (Of course, sometimes it is justifiable, preferred, and necessary NOT to). And, if I do require it, how can I explain the (in my opinion) sloppiness they sometimes see in online communities?
Then I inevitably have students who abandon the good habits they had
  formed and want to make everything an Object, or declare everything as
  var.


These are very different situations. As you observe, the use of var in C# is controversial, but using object as the type of all variables (and then needing to cast any time you want to actually use the variable) is not controversial: it's just wrong.

The first page of answers on the linked SO question about var in C# is incomplete. It doesn't mention that using var can avoid bugs due to typing in one edge case: foreach (var foo in foos) vs foreach (Foo foo in foos). For legacy reasons, if foos is a System.Collections.IEnumerable but not a System.Collections.IEnumerable&lt;&gt; the latter is equivalent to foreach (Foo foo in foos.Cast&lt;Foo&gt;()), which is not especially obvious. (In fact I misremembered and was corrected in comments, which reinforces the advantage of using var here).

TL;DR: blanket prohibitions on var are almost certainly going too far.


  My question is, since these students are still learning, and since it
  is my classroom after all, should I emphatically require that they
  always explicitly specify types unless absolutely necessary? ...
  And, if I do require it, how can I explain the (in my opinion)
  sloppiness they sometimes see in online communities?


var is far from the only controversial subject in programming praxis. The solution in industry is the style guide: whether as a formal written document or as an informal internalised set of opinions which are imparted to new team members by word of mouth when they submit changes which violate the house style. If you're explicitly preparing your students for industry, it is perfectly reasonable to dedicate a bit of time to explaining the concept of the house style, and then when you introduce new material to explain the house style you will enforce for that feature.

The really heavy-duty approach would be to prepare a full industry-style style guide and then to produce a series of increasingly large subsets so that every couple of weeks you can give them a link to an updated style document which specifies how to use the new features you just introduced, or the new features you're about to introduce, and highlights the additions from the previous one.