String.Length is a read/only property, so it’s possibly not the best place to start.

Imagine you have a Person class that needs to store a persons full name.

In Java, you might create a pair of methods, setName() and getName(), to handle this value. That’s two methods, required to handle a single value.

It’s only convention that links those two methods together. Someone who didn’t know the convention – say, someone self taught – might instead write AssignName() and Name() methods. It is, after all, just a convention.

By formalising the relationship into something called a property, C# (and other languages) remove the need for developers to know about, and to adhere to, the same convention as everyone else.

Once you have the unified property, there are other benefits. For example, you can pass a property as an out or ref parameter if you want, you can’t do that with a pair of methods.

As you look across other programming languages, there are other examples of this approach to be found.

• An Interface is “just” a pure abstract class.
• A Delegate is “just” a function as a value.
• MethodMissing() and dynamic are “just” ways for a class to allow you to call methods that don’t exist.
• An event is “just” the way the language supports the Observer pattern.
• The async and await keywords in C# 5.0 are “just” another way to write asynchronous code.
• Extension Methods are “just” static methods.

Except that all of these things are more than what they are “just”. They increase the expressiveness of the language involved, allowing better abstractions and more effective code.

Short Answer: String.Length is a getter property of the string object. It is a read-only property without a set modifier in the .NET Framework.

As suggested, have a look at this comparison – SO discussion on Properties vs Methods

Also read from the official documentation of String.Length

The difference comes from the fact the some languages have different naming contexts for different stuff. I will speak in examples and not so precise definitions as to be more clear.

Example 1: JavaScript – single naming context

• functions are callable which when called execute code, might have side effects and return value
• objects are, well… anything but null and undefined, even functions, primitives etc.
• all these have names, so when you use a name to connect an object or function to another object they all become properties of the new object and that’s it.

So:

var object = {};
// they all share the same naming context of object
object.fn = function() {}; // adding a function property which becomes a method
object.number = 1; // adding a primitive type property
object.object = {}; // adding an object property
// object.fn = 2; // will overwrite the method

Example 2: Java – double naming context

• functions are callable, execute code, side effects, might return value
• functions can’t exist if they are not attached to an object by having some name thus becoming methods (method is a function which has this)
• all functions share same naming context on an object, and can even have more than one with the same name only if they have different parameters
• anything other than function, which is an object or primitive, can also be connected to an object by a name and they share different naming context from methods

Thus:

class JavaObject {
    public void property(){}; // function attached to an object is called method
    public void property(int){}; // multiple functions with same name allowed
    public int property;  // the same name, but in a different context, still ok
    //public long property; // this one's name wiil clash with the int property
}

Long story short:
Some languages can have methods and non-methods as properties with the same name, thus we try to point out which of them we talk about.