You could have a static class
like so;
public static class Strings
{
public const string Space = " ";
}
And use it in your code like;
FullName = FirstName + Strings.Space + MiddleName + Strings.Space + LastName;
However, the ultimate goal is to make the code maintainable, be reasonably efficient and reduce the likelihood of errors. With that in mind, it's best to reduce the number of concatenations and supply just the values that are needed. To that end a simple format string would be a cleaner approach; (pre C#6);
FullName = string.Format("{0} {1} {2}", FirstName, MiddleName, LastName);
And if C#6+;
FullName = $"{FirstName} {MiddleName} {LastName}";
Why would you use those last two approaches? Well, it comes down to separation of concerns. Leave the string formatting to string.Format()
and simply supply the values you need. You reduce the likelihood of errors by having fewer components in the mix, decrease maintenance overhead by the same and increase efficiency by reducing the number of strings involved to perform the concatenation.
EDIT
As for "Why doesn't c# support extension properties?", I'd extract a quote from Lindos Pechos's link from the C# language development team;
It was of course immediately obvious that the natural companion to extension methods is extension properties. It's less obvious, for some reason, that extension events, extension operators, extension constructors (also known as "the factory pattern"), and so on, are also natural companions. But we didn't even consider designing extension properties for C# 3; we knew that they were not necessary and would add risk to an already-risky schedule for no compelling gain.
Basically it boils down to "There wasn't a compelling need" for extension properties to allow you to create something like string.Space
. Maybe in future versions.