Are these good features to use?

[David Thielen]

Hi;

I've got 2 questions about features in the new C#.

The first is where I can do "var x = new MyObject()" instead of
"MyObject x = new MyObject()". This strikes me as a step back to Basic
as it's good to explicitly declare what I'm creating. Am I just being
too resistent to change? Or do others find this not a feature to use.

My second is the auto-properties where a private variable is just
marked as a property. O see this as being more useful, but again I
think having it written in code makes it clearer. What do people who
are using this think of it?

thanks - dave

david@at******@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com

Cubicle Wars - http://www.windwardreports.com/film.htm

[Peter Duniho]

On Mon, 22 Sep 2008 10:16:57 -0700, David Thielen <th*****@nospam.nospam>
wrote:

The first is where I can do "var x = new MyObject()" instead of
"MyObject x = new MyObject()". This strikes me as a step back to Basic
as it's good to explicitly declare what I'm creating. Am I just being
too resistent to change? Or do others find this not a feature to use.

It's a matter of taste. I'm resistant to change :) and thus I prefer the
"old school" declaration style. Others argue that using "var" minimizes
characters to type and doesn't lose any semantic information. The latter
is true, as long as you're initializing the variable in the simplest way,
by calling a constructor for the type, which means that the name of the
type is in fact in the same statement.

Personally, I prefer consistency over efficiency. In programming, I've
run into numbers of errors due to an attempt to be efficient, but I've
never run into any serious error due to an attempt to be consistent. You
can't use "var" without losing human-readable type information in all
scenarios and it's not even legal in other scenarios, so there will always
be some variables that should or must be declared with an explicit type.

That means that at least some of the time, you'll have to look to the
precedent of the variable name to know the type of the variable. Since I
would rather know that if I'm going to have to look there some of the
time, I can look there _all_ of the time, I go ahead and always use an
explicit type.

The exception being the situations for which "var" was actually designed:
anonymous types, inferred by the compiler from the initializer of the
variable. Obviously, there's no valid type name that could be used and
"var" has to be used.

My second is the auto-properties where a private variable is just
marked as a property. O see this as being more useful, but again I
think having it written in code makes it clearer. What do people who
are using this think of it?

I use it when I can. Honestly, it doesn't come up that often; adding code
to a property getter or (especially) the setter is just too useful. But
when you're truly just getting and setting a value with no additional
work, it's not to not have to write everything out explicitly.

I can't imagine how writing the property out explicitly could be clearer
than the auto-property syntax. If anything, the verbosity gets in the way
of understanding the property. With the auto-property, it's an easily
recognized pattern and reading it you immediately know everything there is
to know about the property. With the drawn-out version, you have to scan
more code just to determine that the property does nothing other than
getting and setting a single value.

Note by the way that it's not a matter of having "a private variable just
marked as a property". The auto-properties creates a real property. It's
not just marking some variable as a property. There's underlying storage
that is a separate private variable created by the compiler for the
purpose.

Pete

[Steven Cheng]

Hi Dave,

As for "var" like anonymous variable in C# or VB.NET(.net 3.5), they're
different than the original VB6 or VB.NET's var, they're not late binding
code. They're still strong-type code, but just provide a mechanism to let
the compiler help choose the appropriate type which is necessary to support
those new cool features such as LINQ.

IMO, as long as your code doesn't use a feature that does require you to
declare variables as var, it is always good practice to explicitly declare
the type. Which adds code's readability.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subs...#notifications.

[David Thielen]

Thank you both. Ok, I'm sticking with explicit declarations of
variable types but I'll switch over to the auto properties.

thanks - dave
On Tue, 23 Sep 2008 06:39:07 GMT, st*****@online.microsoft.com
("Steven Cheng") wrote:

>Hi Dave,

As for "var" like anonymous variable in C# or VB.NET(.net 3.5), they're
different than the original VB6 or VB.NET's var, they're not late binding
code. They're still strong-type code, but just provide a mechanism to let
the compiler help choose the appropriate type which is necessary to support
those new cool features such as LINQ.

IMO, as long as your code doesn't use a feature that does require you to
declare variables as var, it is always good practice to explicitly declare
the type. Which adds code's readability.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

================================================= =
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subs...#notifications.

david@at******@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com

Cubicle Wars - http://www.windwardreports.com/film.htm

[OD]

The first is where I can do "var x = new MyObject()" instead of

"MyObject x = new MyObject()". This strikes me as a step back to Basic
as it's good to explicitly declare what I'm creating. Am I just being
too resistent to change? Or do others find this not a feature to use.

As said by others here, "var" in C# is always a "normal typed
variable".
use it to write more readable code.
it is certainly very useful for initialized variables like this :

MyVeryLongClassName x = new MyVeryLongClassName();

I think "var x = new MyVeryLongClassName()" is a much better and
readable syntax. As the variable is initialized on the same line, it's
easy to quickly guess it's type.

On the other hand, when init is done by a method, I think it's not a
good solution cause you can't guess the variable type (C# can, but
you're not a compiler :-).

So :

var x = anObject.Foo();

is not usable, IMO. Because you can't guess what's the returning type
of "Foo()". The compiler knows it, but not the developer reading the
code. This is here a bad use of "var" (always IMO).

My second is the auto-properties where a private variable is just
marked as a property. O see this as being more useful, but again I
think having it written in code makes it clearer. What do people who
are using this think of it?

using properties is always cleaner than giving direct access to public
variables. So auto-properties is a quick way to create properties than
can, later, be custumized to implement side-effects.
No good reason for not using this new syntax.

--
OD___
www.e-naxos.com