We Keep Coding

Why Getter in Anonymous Types?

Why to access a value in an anonymous types, a compiler creates a getter method? Would not it be easier to give a direct access to read-only backing field?

Because properties of anonymous types are readonly after construction. You cannot change them once the object has been created.
They can achieve this using a get only property, but not with a public field (you can always change a field).
EDIT: I've looked around but couldn't find an obvious reason as to why they didn't go with public read-only fields. However, my best guess is: so that you can have properties.
If they had exposed public fields, and didn't have any properties, inevitably, anonymous types would be unusable by things that look for public properties, e.g. WPF binding. So having properties with private readonly backing fields probably was the safer choice.

It's not obvious why they don't simply use a read-only property, but a good reason is this:
If they just used a read-only property, you would know its name and therefore it would be easy to use reflection to change it.
Because they generate a private backing field, it's much harder to know what the name of it is (you'd have to inspect the generated IL), and therefore you are much less likely to change it using reflection. You still could, of course - but it would be such an obviously weird thing to do that you are definitely going to think once or twice before doing so.

Why using only setter in property declaration?

int MyProperty { set; }
What's the idea for using only setter on property? If we set one property with some value, I guess it's very likely to read this value at some point ?

Write-only properties are rare in the Base Class Library, but XmlReaderSettings.XmlResolver is one example. Based on the security note in that topic, I believe the get accessor was omitted to prevent partially trusted code from accessing or tampering with the default resolver.
XmlResolver.Credentials and XmlTextReader.XmlResolver are probably write-only properties for the same reason.
(Strangely, XmlAttribute.InnerText is also a write-only property, but this doesn't seem to be good design.)
Following the above examples, I'd say you should use a write-only property only when a read-write property would otherwise make sense, but you don't want a get accessor for security reasons.
You could of course use a Set method instead, but a property has the advantage that it can be used in an object initializer, as is commonly done with XmlReaderSettings.

You normally don't create a property like this. As you say, it doesn't have much value.
If you really want to allow only setting a certain value without reading it, then provide a method. That's cleaner.

It doesn't make a whole lot of sense to have an auto-property with only a setter. It can make sense to have a manually implemented property with only a setter that can then set a field used internally, but not visible externally.
Having a set only property is very uncommon, and are often implemented with a set method instead of a property as a set-only property is not expected behavior for most developers.
In fact, it is a compiler error for an auto-implemented property to define a set without a get. A set-only property must be manually defined.

A method would make much more sense than a 'write only property' - even if the code did compile. There is an interesting discussion around write only proprties Here

Why are C# auto-implemented properties public?

In all the examples I see, C# auto-implemented properties are made public, even in the MSDN documentation examples. Coming from a C++ background, I've always been taught that it is a good idea to make member data private, unless there is a good reason not to.
Why is the following never used (at least I've never seen it):
private Name { get; set; }
I've looked through the MSDN documentation and read several tutorials regarding auto-implemented properties but there does not seem to be any advice on their pros and cons and when they should be avoided. Do auto-implemented properties compromise program security? Are there situations where they should be avoided? In which situations are they the ideal choice?
Thanks.

You are correct that auto-implemented properties that simply expose a backing field are not much of a gain over a public field.
As Alan Kay said:
But most people who use setters simply use them to simulate direct assignments to interior variables, and this violates the spirit and intent of real OOP.
However, there is an advantage to an auto-implemented property over a public field, and that is that it's a non-breaking change to later revise the implementation. If you have a public field, and code outside your class manipulates that public field, you can't change it to a private field in a future version of the class, or else any other code that touches that field will have to be recompiled. By contrast, once you have a public property, you can revise the implementation of that property in a future version, and client classes can continue using it with zero changes.
So it's useful to use auto-implemented properties for properties that right now would have trivial getter and setter implementations, but that may have more complex implementations in the future.

Have you asked yourself why you've always been taught that it's a good idea to make members private?
It's because (among other reasons) fields are an implementation detail. The detail of "storing data in memory", and it is an unimportant detail to any object which wishes to retrieve or set the data. Another class doesn't need to care whether he can access some memory slot somewhere - he just wants an interface for which he can pass or retrieve a value - there are the getters and setters, or properties.
Having decoupled the property from the detail of "memory based storage", we're given a large number of advantages. Primarily - we can override the behaviour of getting and setting without upsetting any code which uses the property. We can also use the property as an abstraction for retrieving data over a number of different implementations. That becomes extremely useful for testing/mocking behaviour, and providing alternative storage. If other classes depend on the implementation detail of "memory storage", you are not going to be able to change the behaviour of your class without breaking all those.
Before auto properties came along, we would typically store a field and create a getter and setter to encapsulate it for the reasons described above. An auto property automates that for us. We might write code that commonly uses fields everywhere in code, but we do so holding the idea of "I'll do this as a field for now, but that may be subject to change later if the criteria change".
Since a class knows about it's own implementation, it's usually a pointless endeavour to create private auto properties, you're not hiding the detail that's already known. Protected auto properties can be useful if you need to expose to subclasses.
As for situations where they should be avoided: When you want readonly data. (data which will not change after the object is constructed). Auto-properties lack the syntax to allow you to create an automated property that's backed by readonly data.

Auto implemented properties have a private backing member. Compiler adds them for you. Its just a shortcut for
private int _aMember;
public int AMember {
get {return _aMember;}
set {_aMember = value;}
}
You use them you have no real logic in the getter/setter (other than needing to encapsulate).

Auto-implemented properties are just a shortcut for a common pattern. Any time you would have a private member with corresponding get and set functions in C++, you can accomplish the same thing with an auto property in C#. They don't introduce any different best practices or security issues.

Auto-implemented properties with public getters and setters are shortcuts for private backing fields with trivial get and set implementations.
You should think of them as akin to private fields with public get and set methods in C++. That's a role for properties on C#.

Properties aren't "member" data. They are kind of your
const T& field() const;
T& field();
type of things, or get and set methods, i.e. they are accessors.
If you don't need member exposed, don't express them in properties.
In the case of autogenerated ones, you can simply (as of C# 2.0 afaik) write
int SomeProperty { get; private set; }

Do private classes need to be accessed by properties?

I am using an instance of a private class as the state object supplied to a stream.BeginRead operation. (The class is private to my main stream reading/writing class.)
public class MainClass
{
// ...
private class ResponseState
{
public IResponse response;
public Stream stream;
public byte[] buffer = new byte[1024];
}
}
Access to the class is via the fields directly. Should I really be providing access to the class via properties in this case, even though it is only to be used for holding state?
Interested to know what others do.

It's not required by the C# language, but it is good practice never to expose a field directly for maintainability reasons - it is suggested to use a property instead.
See StyleCop SA1401: FieldsMustBePrivate.
TypeName - FieldsMustBePrivate
CheckId - SA1401
Category - Maintainability Rules
Cause
A field within a C# class has an access modifier other than private.
Rule Description
A violation of this rule occurs whenever a field in a class is given non-private access. For maintainability reasons, properties should always be used as the mechanism for exposing fields outside of a class, and fields should always be declared with private access. This allows the internal implementation of the property to change over time without changing the interface of the class.
Fields located within C# structs are allowed to have any access level.
How to Fix Violations
To fix a violation of this rule, make the field private and add a property to expose the field outside of the class.
If your class is purely state for the containing class then you could consider placing the members directly inside the class that uses them. If your class is more than just state (and I suspect it is) then it should follow the usual maintainability rules.

I would - encapsulation is useful inside the class as well as outside the class. By funneling all access to a member through a well know interface (i.e. the property) you are giving yourself the flexibility to add logic around that access later without changing calling code.
It may seem like overkill but honestly, given automatically implemented properties, it is so easy to declare a property that you may as well go ahead and use one to give yourself maximum flexibility.

In my organization, when a class was private or internal, and it's a entity class, we used public fields to access it.
However, since C# 3.0 we use automatic properties, so we always use properties to access private fields.
Anyway, the effect is the same, in our case it was to do the code more readable.

Best practice is to use properties for every member accessible by other types. Automatic properties at C# 3.0 makes this quite easy.

I have just done some reading on this a week or two ago. There are the two camps. One the majority say you must wrap in the property because my teacher said so and everyone else does it. They say that is easier to add extra logic to a property or more maintainable and some other weak reasons. The other camp, call themselves "the true OO guys" tend to be along the line of if you use properties at all you are doing it wrong (with some exceptions of course). Your case would be the exception as far as I can tell. Actually, thinking about it, they would probably still say you are doing it wrong :) Just cant win. Anyway, they also say if you are going to use them don't bother wrapping unless you need the extra logic in your setters and getters. Why slow your program down for nothing. (apparently they can measure how slow too).
I tend to use properties over fields as I do a lot of MVVM and need to implement INotifyPropertyChanged which requires them. In your case I wouldn't worry about wrapping them in properties just makes for pointless fat. But if it was in a class that needed a property then I would wrap them to keep things similar in that class.
If after all that you didn't wrap them, and needed to later, it's a right click refactor->encapsulate field to wrap a property if you have Resharper.

public variables vs private variables with accessors

Has anyone else seen people do this:
private string _name;
public string Name{ get{ return _name; } set{ _name = value;}}
I understand using accessors if you are going to exercise some sort of control over how it gets set or perform some sort of function on it when there is a get. But if you are just going to do this, why not just make the variable public to begin with? Am I missing something?

If you make the member a public field, then you can't later refactor it into a property without changing the interface to your class. If you expose it as a property from the very beginning, you can make whatever changes to the property accessor functions that you need and the class's interface remains unchanged.
Note that as of C# 3.0, you can implement a property without creating a backing field, e.g.:
public string Name { get; set; }
This removes what is pretty much the only justification for not implementing public fields as properties in the first place.

If you define a public interface with a property in assembly A, you could then use this interface in assembly B.
Now, you can change the property's implementation (maybe fetching the value from a database instead of storing it in a field). Then you can recompile assembly A, and replace an older one. Assembly B would carry on fine because the interface wouldn't have changed.
However, if you'd started off initially with a public field, and decided this wasn't suitable and wanted to change the implementation and to do that you needed to convert it to a property, then this would mean you'd have to change assembly A's public interface. Any clients of that interface (including assembly B) would also have to be recompiled and replaced to be able to work with this new interface.
So, you're better off starting with a property initially. This encapsulates the implementation of the property, leaving you free to change it in the future without having to worry what clients (including assembly B) are already out in the world using assembly A. Because, if there are any clients already out in the world making use of assembly A, changing the interface would break all clients. If they're used by another team in your company, or another company, then they are going to be not happy if you break their assemblies by changing the interface of yours!

The idea is that if you use accessors, the underlying implementation can be changed without changing the API. For example, if you decide that when you set the name, you also need to update a text box, or another variable, none of your client code would have to change.

It might be worth noting that DataBinding in .NET also refuses to work off public fields and demands properties. So that might be another reason.

Good programming practice. This is a very common pattern that fits with OO design methodologies. By exposing a public field you expose the internals of how that data is being stored. Using a public property instead allows you more flexibility to change the way the data is stored internally and not break the public interface. It also allows you more control over what happens when the data is accessed (lazy initialization, null checks, etc.)

Variables are part of the implementation of a class. Properties more logically represent the interface to it. With C# 3.0, automatically implemented properties make this a breeze to do from the start.
I've written more thoughts on this, including the various ways in which changing from a variable to a property breaks not just binary compatibility but also source compatibility, in an article on the topic.

Preparation. You never know when you'll want to removed the set accessor down the road, perform additional operations in the setter, or change the data source for the get.

Publicly accessible members should typically be methods and not fields. It's just good practice, and that practice helps you ensure that the encapsulated state of your objects is always under your control.

For encapsulation, it is not recommended to use public fields.
http://my.safaribooksonline.com/9780321578815/ch05lev1sec5?displaygrbooks=0
As Chris Anderson said later in this book, it would be ideal would be if the caller were blind to the difference of field vs. property.

To retain a high degree of extensibility without the pain of re-compiling all your assemblies, you want to use public properties as accessors. By following a "contract" or a defined mechanism that describes how your objects will exchange data a set of rules will be put in place. This contract is enforced with an interface and fulfilled by the getters and setters of your class that inherits this interface.
Later on, should you create additional classes from that interface, you have flexibility of adhering to the contract with the use of the properties, but since you are providing the data via the getters and setters, the implementation or process of assembling data can anything you want, as along as it returns the type that the "contract" expects.