Microsoft suggested that variable names should not match field names. However I saw this extensively in Java (e.g., this tutorial), especially in setters and constructors. So, among these two styles:public class Class {    private int var;    public void set(int var) { this.var = var; }    public int get() { return var; }}orpublic class Class {    private int var;    public void set(int varIn) { var = varIn; }    public int get() { return var; }}Generally speaking, which one is preferred?Does it depend on language (Java, C++, C#, etc.)?editThanks everyone, but I don't worry much about Ruby and Objective-C where it is clear (either a coding convention or just the syntax). AFAIK, there is not a widely accepted convention on this in Java and C++ and that's why I'm concerned. (In C# we should probably just follow Microsoft without reasoning?)
Can variable names match field names?
object oriented;object oriented design
You are asking several different questions here.Can variable names match field names?It depends on the language. In some, they can. In some, they can but one will shadow the other. In some, they can't.Generally speaking, which one is prefered?It depends on the language. Or, more precisely, on the coding standards of any particular organization, which will, however, often be inspired by the community coding standard of the language (if one exists).Does it depends on language (Java, C++, C#, etc.)?Yes.In Ruby, for example, it is possible to have getters and setters look like this, and some people prefer this style:class Foo  def bar    @bar  end  def bar=(bar)    @bar = bar  endendI, and some others prefer this style:class Foo  def bar    @bar  end  def bar=(val)    @bar = val  endendNote, however, that this question will actually present itself much less often than you think, because any self-respecting Ruby programmer would not write such repetitive code by hand but instead synthesize it:class Class  def generate_getter(*names)    names.each do |name|      define_method(name) do        instance_variable_get(:@#{name})      end    end  end  def generate_setter(*names)    names.each do |name|      define_method(:#{name}=) do |val|        instance_variable_set(:@#{name}, val)      end    end  end  def generate_getter_and_setter(*names)    generate_getter(*names)    generate_setter(*names)  endendclass Foo  generate_getter_and_setter :barendIn fact, this pattern is so common, that these methods are actually shipped as part of the core library under the names of Module#attr_reader, Module#attr_writer, and Module#attr_accessor:class Foo  attr_accessor :barendIn Java, OTOH, it seems to be very common to actually write out each and every getter and setter in full, no matter how trivial, and not generate or synthesize them. So, the question presents itself much more often, and thus it is much more likely that there will be coding standards governing it. In particular, if most of your getters and setters are trivial, then the potential for confusion is rather low (how confused can you get in a method that is only a single trivial line?), and thus, it is more acceptable to use the same name for the parameter of the setter and the backing field:void setBar(X bar) { this.bar = bar; }This is a pattern that is easily recognizable, and since there are so many trivial setters, programmers are drilled for this pattern, and thus can spot it even in larger, more complex, non-trivial setters.OTOH, in C#, trivial getters and setters are usually auto-generated, so the only ones where choice of parameter name matters are the non-trivial ones, and thus the potential for confusion is greater, and the programmers aren't used to it that much:X Bar { get; set; } // auto-generated, trivial, programmer doesn't careAnd in the case of a non-trivial setter, the language actually prescribes the name of the parameter (or, more precisely, there is no parameter, rather, there is a special keyword value, which evaluates to the value being passed to the setter), so the only choice is about how to name the backing field. For this, there are no guidelines, since the coding standards only apply to publicly visible code (i.e. public and protected members) and backing fields should be private (otherwise, why have getters and setters at all?). However, since fields should be named camelCase and properties should be named PascalCase, there can be no conflict between them. (This is different in a case-insensitive language like VB.NET, for example!)private X bar;X Bar{    get { return bar; }    set { bar = value; }}or private X _bar;X Bar{    get { return _bar; }    set { _bar = value; }}These two seem to be the predominant styles in the .NET community. Both of them actually violate some naming standards (Don't name identifiers only differing in case and Don't use underscores), but those standards only apply for public identifiers, which the backing field is not. Since large parts of .NET are now open source, it is actually possible to see which naming standards Microsoft itself uses internally, and they seem to favor the second one (underscore prefix). Here is an example from the .NET Concurrent Collections, which are a rather new addition to .NET and thus should reflect fairly recent coding standards:private int _boundedCapacity;public int BoundedCapacity{    get    {        CheckDisposed();        return _boundedCapacity;    }}