Re: Are these good features to use?
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Mon, 22 Sep 2008 10:50:10 -0700
On Mon, 22 Sep 2008 10:16:57 -0700, David Thielen <thielen@xxxxxxxxxxxxx> 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
.
- References:
- Are these good features to use?
- From: David Thielen
- Are these good features to use?
- Prev by Date: Re: do delegates need to be public methods?
- Next by Date: Re: Containing sets of properties in some sort of object -- please help!
- Previous by thread: Are these good features to use?
- Next by thread: RE: Are these good features to use?
- Index(es):
Relevant Pages
|
