I have the simple class using auto-implemented properies:
Public Class foo
{
public foo() { }
public string BarName {get; set;}
}
I obviously use the variable BarName throughout my class and now need to add logic when the property value is set (it must be all upper case, go figure). Does this mean that I need to now create a private variable for BarName , e.g. _BarName, and change the current BarName variable used throughout my class to _BarName?
Public Class foo
{
public foo() {}
private string _BarName = "";
public string BarName
{
get {return _BarName;}
set {_BarName = Value.ToString().ToUpper();}
}
}
I am trying to make sure I understand the implications of using auto-implemented properties, and what it will entail down the road when/if I need to change something. I am assuming that the refactoring, as shown above, is not a breaking change because the property is basically staying the same; it just took a little work inside the class to keep it that way and add the needed logic.
Another example, which may be more meaningful is that I need to call some method when a setter or getter is used; more then changing the value.
This seems a fair trade off the the lines and lines of code to setup properties.
Does this mean that I need to now
create a private variable for BarName
Yes
and change the current BarName
variable used throughout my class
Do not change the rest of the code in your class to use the new private variable you create. BarName, as a property, is intended to hide the private variable (among other things), for the purpose of avoiding the sweeping changes you contemplate to the rest of your code.
I am assuming that the refactoring, as
shown above, is not a breaking change
because the property is basically
staying the same; it just took a
little work to keep it that way and
add the needed logic.
Correct.
You don't need to change anything. Auto-implemented properties are just syntactic sugar. The compiler is generating the private variable and get/set logic for you, behind the scenes. If you add your own getter/setter logic the compiler will use your code instead of its auto-generated code, but as far as the users of that property are concerned, nothing has changed; any code referencing your property will continue to work.
When using automatic properties you don't get direct access to the underlying "backing" variable and you don't get access to the actual logic that gets implemented in the property getter and setter. You only have access to the property (hence using BarName throughout your code).
If you now need to implement specific logic in the setter, you can no longer use automatic properties and need to implement the property in the "old fashioned" way. In this case, you would need to implement your own private backing variable (the preferred method, at least for me, is to name the private backing variable the same name as the property, but with an initial lowercase (in this case, the backing variable would be named barName). You would then implement the appropriate logic in the getter/setter.
In your example, you are correct that it is not a breaking change. This type of refactoring (moving from automatic properties to "normal" properties should never be a breaking change as you aren't changing the public interface (the name or accessibility of the public property).
Don't use automatic properties if you know that you are going to validate that object. These objects can be domain objects etc. Like if you have a Customer class then use private variables because you might need to validate the name, birthdate etc. But if you are using a Rss class then it will be okay to just use the automatic properties since there is no validation being perform and the class is just used to hold some data.
You are correct about the refactoring and it really shouldn't break anything.
Whether or not you actually need to go through the references within the class to the property name and change those to refer to the private field would depend on whether the internal code needed to access the underlying representation of the data rather than how it was presented to consumers of the class. In most cases you could leave well enough alone.
In your simple example it would be wise to leave well enough alone and ensure that no code internal to the class could subvert the conversion/formatting being performed in the setter.
If on the other hand the getter was doing some magic to change the internal representation of the field into the way consumers needed to view the data then perhaps (in some cases) the internal code within the class would need to access the field.
You would need to look at each occurrence of the access to the auto-property in the class and decide whether it should be touching the field or using the property.
Automatic properties are just syntactic sugar, the compiler in fact creates the private member for it, but since it's generated at compile time, you cannot access it.
And later on, if you want to implement getters and setters for the property, only then you create a explicit private member for it and add the logic.
Related
I'm using .NET 4.5 in a VSTO addin for outlook 2013. I'm having some trouble fully grasping properties and accessors. Auto-implemented accessors which I assume are when you just write get; set; rather than get { //code }, etc. are also giving me trouble. I have a dictionary I use internally in my class. Here is my code:
private Dictionary<string, string> clientDict { get; set; }
private Dictionary<string, string> clientHistoryDict { get; set; }
then later on:
clientDict = new Dictionary<string, string>();
clientHistoryDict = new Dictionary<string, string>();
I am using the same names as the properties in the code later on, within the same class.
I never actually write:
private Dictionary<string, string> _clientDict; // etc.
to create the variables I just was using the property directly.
I tried changing my code to do this, and I had some issues and realized my understanding of properties is a bit mixed up.
Here are a few questions I need clarified that I can't seem to find the correct answer to.
First, is there any reason to use a private property? My dictionaries are never accessed outside of the class or in any derived classes so is there a reason to even use properties? I don't use any special validation or anything in the setter or anything like that.
Second, when I tried to change my code to use variables and then access them via the properties like your typical property example would, I ran into problems. I found an example where the getter was set to return _clientDict, but the setter was just set; It gave me the error: that I must give set a body because it's not abstract or partial. Why would it not auto-implement the setter for me in this instance?
Last, when I call new on the properties in the same class that it is declared in, what is the difference between doing that with a property and a normal variable of the same type? Do properties differ at all from variables in that case? Is it bad practice to use properties this way when it should be accomplished with private variables?
These may be some misguided questions but I can't find any other place that has the information to help me understand these distinctions. I've been playing around with properties to try and figure all of this out but I could use so me assistance.
First, is there any reason to use a private property?
Usually, no. Properties are great for encapsulation. One advantage (there are many more) of using a property is that it can do validations before assignment. When you have something private, you usually don't need to protect things from yourself. Also, properties have the advantage of setting different accessors (private, protected, etc), where fields do not.
Why would it not auto-implement the setter for me in this instance?
We have to understand that auto-implemented properties aren't black magic. The compiler will generate a private backing field for us, instead of providing one ourselfs. From his point of view, he sees that you have a getter that returns a private field, but the setter is automatic, thatusually would indicate some kind of logical error in your code. Why would you return one value but set a completely different one? When you create a property with a backing field, you have to provide both the getter and setters, those are the rules.
when I call new on the properties in the same class that it is
declared in, what is the difference between doing that with a property
and a normal variable of the same type?
Semantically, Nothing. new belongs to the type being constructed and will emit a constructor call. The difference is once the newly created object is assigned. A field will cause the compiler to emit a stfld opcode. For a property it'll emit a call to invoke the property setter. When you access a property, the compiler will end up calling get_YourPropertyName vs a ldfld on the field.
Is it bad practice to use properties this way when it should be
accomplished with private variables?
I wouldn't call it bad practice, but I would find it a bit weird to have a private property.
For more insights on fields and properties, see What is the difference between a Field and a Property in C#?
Is there any reason to use a private property?
No - that's the whole point of auto implementation. It saves you having to write all that extra code when all you want to do is get or set what's in the private member variable. .Net handles the creation of the shadowing private member variable behind the scenes.
When I tried to change my code to use variables and then access them via the properties like your typical property example would, I ran into problems. I found an example where the getter was set to return _clientDict, but the setter was just set; It gave me the error: that I must give set a body because it's not abstract or partial. Why would it not auto-implement the setter for me in this instance?
My understanding is that it's all or nothing with auto implementation. (Open to correction there though). That said I have seen code compile with the set block simply defined as set { }. Edit: Just to clarify the set { } block won't actually set the value, it essentially swallows the call and does nothing - it will compile though.
When I call new on the properties in the same class that it is declared in, what is the difference between doing that with a property and a normal variable of the same type? Do properties differ at all from variables in that case? Is it bad practice to use properties this way when it should be accomplished with private variables?
There is no real difference as far as I am aware. The exact same thing is happening, it's just that .Net is handling the plumbing for you.
I'm fairly new to C#, and I think properties are a wonderful thing. So wonderful, in fact, that I can't see any real advantage to using fields, instead. Even for private fields, it seems like the flexibility and modularity that properties offer can at best save you serious headaches, and at worst have no effect at all.
The only advantage I can see for fields is that you can initialize them inline. But most of the time, you want to initialize them in the constructor, anyway. If you aren't using inline initialization, is there any reason not to use properties all the time?
Edit: Some people have brought up the need to back up properties with fields (either explicitly or automatically). Let clarify my question: Is there any reason to use fields except to back up properties? I.e., is there any time that SomeType someField; is preferable to SomeType SomeProperty { get; set; }?
Edit 2: DanM, Skurmedel, and Seth all gave really useful answers. I've accepted DanM's, as it is the most complete, but if someone were to summarize their responses into a single answer, I'd be happy to accept it.
Typically, properties need a backing field unless they are simple getter/setter "automatic properties".
So, if you're just doing...
public string Name { get; set; } // automatic property
...you don't need a field, and I agree, no reason to have one.
However, if you're doing...
public string Name
{
get { return _name; }
set
{
if (value = _name) return;
_name = value;
OnPropertyChange("Name");
}
}
...you need that _name backing field.
For private variables that don't require any special get/set logic, it's really a judgment call whether to do a private automatic property or just a field. I usually do a field, then, if I need it to be protected or public, I will change it to an automatic property.
Update
As noted by Yassir, if you use automatic properties, there's still a field lurking behind the scenes, it's just not something you actually have to type out. So, the bottom line is: properties don't store data, they provide access to data. Fields are what actually hold the data. So, you need them even if you can't see them.
Update 2
Regarding your revised question...
is there any time that SomeType someField; is preferable to SomeType SomeProperty { get; set; }?
...one thing that comes to mind: If you have a private field, and (according to convention for private fields) you call it _name, that signals to you and anyone reading your code that you are working directly with private data. If, on the other hand, you make everything a property, and (according to convention for properties) call your private property Name, now you can't just look at the variable and tell that it is private data. So, using only properties strips away some information. I haven't tried working with all properties to gauge whether that is crucial information, but something is definitely lost.
Another thing, more minor, is that public string Name { get; set; } requires more typing (and is a little messier) than private string _name.
Just try using a Property when using ref/out args:
someObject.SomeMethod(ref otherObject.SomeProperty);
It won't compile.
Properties are a wonderful thing -- but there is overhead associated with property access. Not necessarily a problem, but something to be aware of.
Avoiding Overuse of Property Getters and Setters
Most people don't realize that property getters and setters are similar to methods when it comes to overhead; it's mainly syntax that differentiates them. A non-virtual property getter or setter that contains no instructions other than the field access will be inlined by the compiler, but in many other cases, this isn't possible. You should carefully consider your use of properties; from inside a class, access fields directly (if possible), and never blindly call properties repeatedly without storing the value in a variable. All that said, this doesn't mean that you should use public fields!
Source: http://dotnet.sys-con.com/node/46342
If you want to have something readonly you pretty much have to use a field as there is no way to tell an automatic property to generate a read-only field.
I do this quite often.
Contrived example:
class Rectangle
{
private readonly int _width;
private readonly int _height;
public Rectangle(int width, int height)
{
_width = width;
_height = height;
}
public int Width { get { return _width; } }
public int Height { get { return _height; } }
}
This means nothing inside of Rectangle can alter the width or height after construction. If one tries to the compiler will complain.
If I instead had used an automatic property with a private setter the compiler wouldn't protect me from myself.
Another reason I see is, if a piece of data doesn't have to be exposed (stay private) why make it a property?
While I agree with what I perceive as the "intent" in David Basarab's statement : "There is no reason to publicly expose fields," I'd like to add a slightly different emphasis :
I'd modify the quote from David above to read : "There is no reason to publicly expose fields ... outside a class ... except through the conscious choice of encapsulating the fields in Properties through which access is rigorously controlled.
Properties are not simply a "veneer" of syntax over Fields "tacked onto" C# : they are a fundamental language feature designed for good reasons including :
controlling what is exposed and not exposed outside classes (encapsulation, data hiding)
allowing certain actions to be performed when a Property is accessed or set : actions that are best expressed in the Property 'get and 'set, rather than being "elevated" to externally defined methods.
Interfaces by design cannot define 'fields : but can define Properties.
Good OO Design means making conscious choices about "state" :
local variable fields : what state is private to a method and transient : local variables typically only valid within the scope of a method body, or even with as "narrow a lifespan" as within the scope of something like a 'for loop. Of course you can regard parameter variables in a method as "local" also.
class instance fields : what state is private to a class, and has independent existence for each instance of a class, but is most likely required to be used in several places in the class.
static instance fields : what state will be a property of the class only, independent of the number of instances of the class.
state deliberately and consciously exposed "outside" the class : the key idea being that there is at least one level of indirection interposed between the class and "consumers" of the data the class exposes. The "flip side" of "exposure" is, of course, the conscious intention of hiding (encapsulating, isolating) implementation code.
a. via public properties : all aspects of this well-covered in all the other answers here
b. via indexers
c. via methods
d. public static variables are usually found in utility classes, which are often static classes.
Suggest you review : MSDN on 'Fields ... MSDN on Properties ... MSDN on Indexers
I don't see why you'd use private autoproperties. What advantage is there to
private int Count {get; set;}
over
private int count
Fields and properties are not interchangeable. I guess what you're saying is accessing private fields through private properties. I do this when it makes sense but for the most part, it's not necessary. The JIT optimizer will inline access to a private field through a private property in most cases anyway. And wrapping a private field in a private property is not considered a breaking change anyway since private members are not a part of your interface.
Personally, I would never expose any protected/public instance fields. It's generally acceptable though to expose a public static field with a readonly modifier as long as the field type is itself immutable. This is often seen with SomeStruct.Empty static fields.
As others have noted, you will need a private backing field for properties anyway.
Also there is a speed advantage in using fields over properties. In 99.99 % of the cases it won't matter. But in some it might.
Fields are the only place you can store state. Properties are actually just a pair of methods with special syntax that allows them to be mapped to the get or set method depending on how they're being used: if a property modifies or accesses state, that state still has to be stored in a field.
You don't always see the fields. With C# 3 automatic properties, the field is created for you by the compiler. But it's still there. Furthermore, automatic properties have some significant limitations (e.g. no INotifyPropertyChanged support, no business logic in setters) that mean they're often inappropriate, and you need to create an explicit field and a manually defined property anyway.
As per David's answer, you're right if you're talking about an API: you almost never want to make the internal state (fields) part of the API.
The syntax for fields is a lot quicker to write than for properties, so when it's safe to use a field (private to the class) why not use it and save that extra typing? If auto-implemented properties had the nice short concise syntax and you had to do extra work to make a plain old field, people might just start use properties instead. Also, it's a convention now in C#. That's how people think, and it's what they expect to see in code. If you do something different form the normal, you will confuse everyone.
But you could ask why the syntax for fields doesn't create an auto-implemented property instead of a field, so you get the best of both worlds - properties everywhere and a concise syntax.
There's a very simple reason why we still need to have explicit fields:
C# 1.0 didn't have all these nice features that we have now, so fields were a fact of life - you couldn't really live without them. Lots and lots of code relies on fields and properties being visibly different things. It simply cannot be changed now without breaking tons of code.
I would suspect also that there are performance implications, but perhaps that can be solved by the jitter.
So we're stuck with fields forever, and since they're there and they've taken the best syntax, it makes sense to use them when it's safe to do so.
There is no reason to publicly expose fields.
If you public expose a field you can't change the source of the information, from inline defination to configuration file without refactoring.\
You could use a field to hide internal data. I rarely favor that, I only use fields when I am doing something to hide publicly and using it in a property. (i.e. I am not using Automatic property generation)
Speed. If a field gets set or read billions of times over the course of a simulation then you want to use a field and not a property to avoid the overhead och a sub routine call. Conforming to OO (DDD?) as far as possible, in these instances, I'd recommend resorting to fields only in class dedicated to representing some sort of "value" like person. Logic should be kept to a minimum. Rather, have a personcreator or a personservicer.
But if you have these issues then you're probably not programming c++ and not c#, aren't you?
There are several good (partial) answers by #Seth (fields perform better, so in a private context you might as well use that to your benefit when it makes sense), #Skurmedel (fields can be readonly), #Jenk (fields can be used for ref/out). But I'd like to add one more:
You can use the streamlined initialization syntax for setting the value of a field, but not a property. i.e.:
private int x = 7;
vs
private int x { get; set; }
// This must go in the constructor, sometimes forcing you to create
// a constructor that has no other purpose.
x = 7;
Seen a few examples of code where this happens:
public class Foo
{
string[] m_workID;
public string[] WorkID
{
get
{
return m_workID;
}
private set
{
m_workID = value;
}
}
}
What's the point of this?
Since the use m_workID unnescessary.
In general, the point is to separate implementation (the field) from API (the property).
Later on you can, should you wish, put logic, logging etc in the property without breaking either source or binary compatibility - but more importantly you're saying what your type is willing to do, rather than how it's going to do it.
I have an article giving more benefits of using properties instead of public fields.
In C# 3 you can make all of this a lot simpler with automatically implemented properties:
public class Foo
{
public string[] WorkID { get; private set; }
}
At that point you still have a public getter and a private setter, but the backing field (and property implementation) is generated for you behind the scenes. At any point you can change this to a "normal" fully-implemented property with a backing field, and you'll still have binary and source compatibility. (Compatibility of serialized objects is a different matter, mind you.)
Additionally, in this case you can't mirror the behaviour you want (the ability to read the value publicly but write it privately) with a field - you could have a readonly field, but then you could only write to it within the constructor. Personally I wish there were a similar shorthand for this:
public class Foo
{
private readonly int id;
public int Id { get { return id; } }
...
}
as I like immutable types, but that's a different matter.
In another different matter, it's generally not a good idea to expose arrays like this anyway - even though callers can't change which array WorkID refers to, they can change the contents of the array, which is probably not what you want.
In the example you've given you could get away without the property setter, just setting the field directly within the same class, but it would mean that if you ever wanted to add logging etc you'd have to find all those writes.
A property by itself doesn't provide anywhere to put the data - you need the field (m_workID) for storage, but it entirely correct to hide that behind a property for many, many reasons. In C# 3.0 you can reduce this to:
public string[] WorkID {get; private set;}
Which will do much of the same. Note that exposing an array itself may be problematic, as there is no mechanism for protecting data in an array - at least with an IList<string> you could (if needed) add extra code to sanity check things, or could make it immutable. I'm not saying this needs fixing, but it is something to watch.
In addition to the Object Oriented philosophy of data encapsulation, it helps when you need to do something every time your property is read/write.
You can have to perform a log, a validation, or any another method call later in your development.
If your property is public, you'll have to look around all your code to find and modify your code. And what if your code is used as a library by someone else ?
If your property is private with appropriate get/set methods, then you change the get/set and that's all.
You can use C# 3.0 auto properties feature to save time typing:
public class Foo
{
public string[] WorkID
{
get; private set;
}
}
In addition properties gives you lot of advantages in comparison to fields:
properties can be virtual
properties hide implementation details (not all properties are just trivial variable accessors)
properties can contain validation and logging code and raise change events
interfaces cannot contains fields but properties
A lot of times you only want to provide read access to a field. By using a property you can provide this access. As you mention you may want to perform operations before the field is accessed (lazy loading, e.g.). You have a lot of code in there that just isn't necessary anymore unless you're still working in .Net 2.0-.
I'm a bit confused on the point of Automatic properties in C# e.g
public string Forename{ get; set; }
I get that you are saving code by not having to declare a private variable, but what's the point of a property when you are not using any get or set logic? Why not just use
public string Forename;
I'm not sure what the difference between these 2 statements is, I always thought you used properties if you wanted additional get/set logic?
Properties can have code put into them without breaking contract, fields can't have code put into them without changing them to properties (and breaking the interface). Properties can be read only or write only, fields can't. Properties can be data bound, fields can't.
You can write
public string Forename{ get; private set; }
to get read-only properties... Still not nearly as versatile as real properties, but it's a compromise that for some works.
I'm not sure what the difference between these 2 statements is, I always thought you used properties if you wanted additional get/set logic?
In the first case, the compiler will automatically add a field for you, and wrap the property. It's basically the equivalent to doing:
private string forename;
public string Forename
{
get
{
return this.forename;
}
set
{
this.forename = value;
}
}
There are many advantages to using properties over fields. Even if you don't need some of the specific reasons, such as databinding, this helps to future-proof your API.
The main problem is that, if you make a field, but in v2 of your application, need a property, you'll break the API. By using an automatic property up front, you have the potential to change your API at any time, with no worry about source or binary compatibility issues.
It is meant that you expect to add the logic later.
If you do so and have it as property from the beginning, you will not have to rebuild the dependent code. If you change it from a variable to a property, then you will have to.
Consider looking at some related threads about Difference Between Automatic Properties and Public Fields, Fields vs Properties, Automatic Properties - Useful or Not?, Why Not to Use Public Fields.
Public data members are evil (in that the object doesn't control modification of it's own state - It becomes a global variable). Breaks encapsulation - a tenet of OOP.
Automatic properties are there to provide encapsulation and avoid drudgery of writing boiler plate code for simple properties.
public string ID { get; set;}
You can change automatic properties to non-automatic properties in the future (e.g. you have some validation in a setter for example)... and not break existing clients.
string m_ID;
public string ID
{
get { return m_ID; }
set
{
//validate value conforms to a certain pattern via a regex match
m_ID = value;
}
}
You cannot do the same with public data attributes. Changing a data attribute to a property will force existing clients to recompile before they can interact again.
When adding auto properties the compiler will add get set logic into the application, this means that if you later add to this logic, and references to your property from external libraries will still work.
If you migrated from a public variable to a property, this would be a breaking change for other libraries that reference yours - hence, why not start with an auto property? :)
For one, you can set the property to virtual and implement logic in an inheriting class.
You can also implement logic in the same class afterwards and there won't be side-effects on any code relying on the class.
Not all properties need get/set logic. If they do, you use a private variable.
For example, in a MV-something pattern, your model would not have much logic. But you can mix and match as needed.
If you were to use a field like you suggested in place of a property, you can't for example define an interface to describe your class correctly, since interfaces cannot contain data fields.
A property is like a contract, and you can change the implemenation of a property without affecting the clients using your classes and properties. You may not have any logic today, but as business requirements change and if you want to introduce any code, properties are your safest bet. The following 2 links are excellent c# video tutorials. The first one explains the need of properties over just using fields and the second video explains different types of properties. I found them very useful.
Need for the Properties in C#
Poperties in C#, Read Only, Write Only, Read/Write, Auto Implemented
Take a look at the following code and explanation.
The most common implementation for a property is getter or a setter that simply reads and writes to a private field of the same type as a property. An automatic property declaration instructs the compiler to provide this implementation. The compiler automatically generates a private backing field.
Look into the following code:-
public class Stock
{
decimal currentPrice ; // private backing field.
public decimal CurrentPrice
{
get { return currentPrice ; }
set { currentPrice = value ; }
}
}
The same code can be rewritten as :-
public class Stock
{
public decimal CurrentPrice { get ; set ; } // The compiler will auto generate a backing field.
}
SOURCE:- C# in a Nutshell
I have classes which have automatic properties only like public customerName {get; set;}. They are public because they are accessed outside the class. They can also be accessed inside the class. They offer good encapsulation and better debugging. I can put a breakpoint on one if I need to know who is accessing it and when.
My question is what are the disadvantages of using properties only with no corresponding fields? I can make the setter or getter private, internal.. etc which means I also have flexibility of scoping it when needed.
Serialization with BinaryFormatter - you have big problems if you need to change your property to a "regular" property later, for example to add some validation / eventing /etc - sinc BinaryFormatter uses the field names. And you can't duplicate this, since the field name the compiler generates cannot be written as legal C#.
Which is a good reason to look at a contract-based serializer instead. See this blog entry for more info.
You can't create truly read only property, because you have to define both setter and getter. You can only use private setter to achieve pseudo-readonly property from outside.
Otherwise, as said above there are no other disadvantages.
There are no disadvantages for simple properties. The compiler creates the backing field for you. This blog entry explains how the compiler treats automatically implemented properties.
Not really a disadvantage, but you have to be aware of the default values of automatic properties. With "classic" properties we always used to initialize the backing fields, e.g. like this:
private bool _flag = true;
public bool Flag
{
get { return _flag; }
set { _flag = value; }
}
This made it obvious what the default value of the property is.
With automatic properties, you have to know what the default values are for the different types (e.g. false for bool). If you don't want the property to have the default value you have to initialize it in the constructor:
class MyClass
{
public bool Flag { get; set; }
public MyClass()
{
Flag = true;
}
}
This means, you have to implement a constructor if you want to initialize your properties to non default values or if a property is of a reference type (class).
But as I wrote, I do not really think of this as a disadvantage, just something you have to know.
The thing is, there is a corresponding field. You just don't see it because the compiler creates it for you. Automatic properties are just syntactic sugar or shorthand way to create the field.
No major things. Just edge cases like where you need to pass a property to a method where the parameter is passed by reference (ref or out) which isn't possible with a property (because internally, they're just get_Property/set_Property methods implemented by the compiler, not special fields of some kind) and you would need an explicit private backing field for this.
EDIT: Oh, and seconding the 'no readonly' properties, which is actually fairly common.
If you don't need to perform any specific logic in the get and/or set accessors, there's no disadvantage...
I say that they are bad from a code readability standpoint. Syntax sugar is nice for writing code but horrible for reading code. As developers the code we leave behind will ultimately be inherited by some poor developer that will have to make sense out of what we did and what is going on in the code. I really am against changing a language to simply save keystrokes when there is an established syntax for the same constructs.