Develop Reference

Why doesn't the C# compiler stop properties from referring to themselves?

If I do this I get a System.StackOverflowException:
private string abc = "";
public string Abc
{
get
{
return Abc; // Note the mistaken capitalization
}
}
I understand why -- the property is referencing itself, leading to an infinite loop. (See previous questions here and here).
What I'm wondering (and what I didn't see answered in those previous questions) is why doesn't the C# compiler catch this mistake? It checks for some other kinds of circular reference (classes inheriting from themselves, etc.), right? Is it just that this mistake wasn't common enough to be worth checking for? Or is there some situation I'm not thinking of, when you'd want a property to actually reference itself in this way?

You can see the "official" reason in the last comment here.
Posted by Microsoft on 14/11/2008 at
19:52
Thanks for the suggestion for
Visual Studio!
You are right that we could easily
detect property recursion, but we
can't guarantee that there is nothing
useful being accomplished by the
recursion. The body of the property
could set other fields on your object
which change the behavior of the next
recursion, could change its behavior
based on user input from the console,
or could even behave differently based
on random values. In these cases, a
self-recursive property could indeed
terminate the recursion, but we have
no way to determine if that's the case
at compile-time (without solving the
halting problem!).
For the reasons above (and the
breaking change it would take to
disallow this), we wouldn't be able to
prohibit self-recursive properties.
Alex Turner
Program Manager
Visual C# Compiler

Another point in addition to Alex's explanation is that we try to give warnings for code which does something that you probably didn't intend, such that you could accidentally ship with the bug.
In this particular case, how much time would the warning actually save you? A single test run. You'll find this bug the moment you test the code, because it always immediately crashes and dies horribly. The warning wouldn't actually buy you much of a benefit here. The likelihood that there is some subtle bug in a recursive property evaluation is low.
By contrast, we do give a warning if you do something like this:
int customerId;
...
this.customerId= this.customerId;
There's no horrible crash-and-die, and the code is valid code; it assigns a value to a field. But since this is nonsensical code, you probably didn't mean to do it. Since it's not going to die horribly, we give a warning that there's something here that you probably didn't intend and might not otherwise discover via a crash.

Property referring to itself does not always lead to infinite recursion and stack overflow. For example, this works fine:
int count = 0;
public string Abc
{
count++;
if (count < 1) return Abc;
return "Foo";
}
Above is a dummy example, but I'm sure one could come up with useful recursive code that is similar. Compiler cannot determine if infinite recursion will happen (halting problem).
Generating a warning in the simple case would be helpful.

They probably considered it would unnecessary complicate the compiler without any real gain.
You will discover this typo easily the first time you call this property.

First of all, you'll get a warning for unused variable abc.
Second, there is nothing bad in teh recursion, provided that it's not endless recursion. For example, the code might adjust some inner variables and than call the same getter recursively. There is however for the compiler no easy way at all to prove that some recursion is endless or not (the task is at least NP). The compiler could catch some easy cases, but then the consumers would be surprised that the more complicated cases get through the compiler's checks.

The other cases cases that it checks for (except recursive constructor) are invalid IL.
In addition, all of those cases, even recursive constructors) are guarenteed to fail.
However, it is possible, albeit unlikely, to intentionally create a useful recursive property (using if statements).

Is Resharper correct?

I just installed Reshaper 4.5 and it has come up with the following suggestions:
return this.GetRuleViolations().Count() == 0; -- REMOVE this.
new string[] { this.ID.ToString(), this.Registration } -- REMOVE string, MAKE ANONYMOUS TYPE
int i = Method.GetNumber(); -- REPLACE int WITH var
Should I do these?
I think in some cases it is going to make the code less readable but will it improve performance? what are the benefits of making these changes?
Thanks

1) The explicit this pointer is only necessary when the reference would otherwise be ambiguous. Since GetRuleViolations is defined on the type, you most likely do not need this.
Another point here is that if GetRuleViolations return an IEnumerable of something, you will generally be much better off using Any() instead of Count() == 0 as you risk enumerating the entire sequence.
2) String can be inferred from the initialization.
3) Resharper prefers var over specific types.

Apart from the obvious benefit of your little square going green, if you are writing code that will be maintained by someone else later, it makes good sense not to use your personal preference in coding syntax. Resharper is becoming useful in formatting code in a way that is recognisable to a very wide audience.
I belong to the school of thought that says it doesn't matter who's way is right. If we all stick to a pattern, we'll all find it easier to read each others code.
So, in my humble opinion, don't change the default resharper settings. Just accept that if you use the defaults, you make life simple for everyone.

I think the first one is for the purpose, if you want to make "GetRuleViolations()" a static method. Then you have not to remove the "this" identifier.

For the 3rd one - the one that annoys me the most. It provides the reader with less information and i think it's just a matter of showing off a newish feature.
I'd say - use var when you know the return type and use the correct object type when you do not like this:
var reader = new XmlReader(.... // Implicit
XmlReader reader = SomeClass.GetReader() // Explicit when you can't be sure

First one: Resharper is asking about removing this which is just a style thing to me. Nothing more, keeping it won't harm performance in any way. It is just a matter of readability.
For second and third: Resharper normally prefers using var instead of specific data type, that's why the suggestions. I believe it is a matter of personal choice and provides no extra gain other than readability.

The first seems unclear to me. You usually don't have to prefix this. as long as there are no ambiguities, which I cannot tell from this example. Resharper is probably right. The other two won't improve performance, the compiled result will be the same. It's just a matter of taste and, of course, your coding guidelines.

The first one should be configurable. As far as I remember, you can tell ReSharper whether you want to have "this." in front of only fields, methods, both or none.
Using "var" will not change anything in the generated CIL code, so the performance will stay the same. I haven't used ReSharper for some time and I don't know why it promotes anonymous types so aggressively, but one advantage of "var" is that it's more resistant to change.
Meaning if, instead of calling Method.GetNumber(), you called a wrapper, eg. Filter(Method.GetNumber()) in the same line that returns a Nullable, you won't have to update the variable's type.

None of these will have any effect on performance, only on readability.
I find suggestions 1 and 2 to be more readable, and 3 less readable than your original code.
But you don't need to just follow these suggestions if, e.g., you find them less readable or if they violate your company's code style standard. When you put the cursor on the squiggly line, press Alt-Enter to show the list of Contex Actions. One of them will be to to change the severity of the inspection; you can not show it at all or show it as a hint. You can find a complete list of inspections at ReSharper | Options | Code Inspection | Inspection Severity.

Do you use 1-3 letters variables EVERYWHERE? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I notice, in C# i use very short variable names EVERYWHERE. My code is polluted with
foreach(var (v|f|i) in SOMETHING)
for(int (i|n|z)=0
var (ret|r) = blah();
...
return ret;
var sw = new StringWriter();
using(var r = cmd.ExecuteNonQuery()) {
while(r.Read()) {
r.GetSomething(3)
I dont know if this is bad or ok. I can certainly read it. I havent looked at code 5months ago or older so i cant say if i understand old code. All my functions are short and do one thing so by reading the function you can get a good idea what the variable is, especially since theres <=5vars in a function.
People use to yell at me about not using good variable names. Am i not using good variable names or is this ok?

Write code for humans to read. A good rule of thumb is the bigger the scope in which a variable is used, the more descriptive its name should be. Function parameters especially should have very descriptive names, with the exception of functions where it is obvious what the parameter does, as in
double sqrt(double n)
However, if it's something commonly given a short name and used in a small scope, then use a short name. Examples:
//these are okay
var sb = new StringBuilder();
var sw = new StringWriter();
var cmd = new SqlCommand();
for(var i = 0; i< count; i++) {}

Unless your code is minified, you shouldn't see vars like this all over the place. Your code should be effortlessly intelligible.
I recall hearing that we ought all code as if the next person to manage our project is a psychopathic killer who knows where you live.

Using short variable names for local variables is okay as long as the scope is limited.
Personally, I find that for simple usage short concise variable names tend to be easier to read than longer ones.
using (StreamReader sr = new StreamReader(inputStream))
{
sr.ReadByte();
}
As opposed to:
using (StreamReader streamReader = new StreamReader(inputStream))
{
streamReader.ReadByte();
}
It's really all about readability. Every situation is different, and developer teams are different. Follow the coding standard for the project, if that exists. If not, follow the style of existing codebase, if that exists.
I agree with some of the answers here say that variables names should have good names. But I believe that presupposes that an object has semantic value. Sometimes, it doesn't. In some cases, you just need an instance of a specific object to perform some small task, after which it becomes irrelevant. In cases like this, I believe that abbreviated identifiers are acceptable.
Note: Just because the usage of a variable is limited in its scope does not necessarily mean that an meaningless name is okay. If there is a good name that represents what the object does, then it should be used. If you can come up with a variable name that answers 'Why?', then that name is far preferable.
Also, using 'i' and 'j' for for indexes is well understood by developers. By convention, loop counter variables have been named this way since the days of FORTRAN.
for (int i = 0; i < 10; i++)
{
for (int j = 0; j < 10; j++)
{
PerformOperation(i,j);
}
}

Some years ago I discovered what happens if I made my functions short:
I could understand them. My brain is small, and long functions don't fit.
Classes get complicated (lots of functions). But Extract Class produced small, cohesive, single-purpose classes. Again, small brain, so small classes required.
The number of variables in a function (or class) is small. Remembering which is which from declaration time to use time is easy, because the distance is short.
The number of scopes in my functions is small, so I don't have to figure out which variables go where.
With all of that in place, how I name my variables doesn't matter much. The names don't have to make up for code that is otherwise hard to understand.
Since the number of variables in a scope is small, and the purpose obvious, I rarely need to put any effort in to choosing a descriptive name. Since I don't want to strain my small brain any more than I have to, I never abbreviate. My default name for a variable is the name of the type. E.g. class Foo goes in variable foo. In my code, if it's ever something different, you know something special is happening, and you should pay attention.
In the old days, my no-abbreviation habit would have produce unwieldy code, but since my methods and classes are small, the code doesn't suffer.

It's not just a matter of good variable names (which is a good idea) but rather if someone else could make sense of what you've written relying on the comments as well as the variable names.
Sure, for things like counters or simple actions short and concise names make sense. For more complex algorithms or something that is a little harder to read, you'll want to elaborate to the extent that the code is clear.
Every shop and every developer is different. At the end of the day, try to write your code with consideration for the next guy that might have to maintain it.

Using one letter variable names as indexes in loops or in short well defined blocks is normally considered ok. However, there is nothing wrong with using descriptive camel case names that convey meaning to others reading your code, for things like function arguments and local variables.

With limited exceptions, no - this is not OK. There's just no excuse any longer for single letter or overly abbreviated variable names. Even if you're a hunt-and-peck typist, intellisense means you almost never have to spell anything out. If you continue to name variables this way you are punishing both yourself any anyone unfortunate enough to be tasked with maintaining your code.

Would I consider it a bad coding style? Well, yes.
If you were working with me on same code I'd repeatedly remind you to name your variables better. In short, good code should be readable by other developers without much trouble and good variable names help a lot. Maybe you don't have problems reading your code even after a while, but the question is whether someone who has never worked on that good would be equally fine with it.
There are a few exceptions where I think that short variable names are okay:
Indexes (mostly in for loops) such as:
for (int i = 0; i < 10; i++)
{
}
Variables used in a very limited scope, such as Linq queries, lambda expressions or some of the examples already mentioned like Streamwriters and -readers and such are another example where I think that short variable names are fine.
Furthermore it's always a question of how readable your code eventually is. The reason why I would be constantly nagging at people who use short variable names is that for me that it is an indicator that they generally don't care about how readable their code is (especially for others).

I have no idea how you can keep track of things when you have variable names like that.
Generally, its much better to have longer names that actually describe the variables. The thing to strive for is for anyone to be able to read the code and understand whats going on, to be able to understand what they are for etc =)

It seems like the average length of my variable names increases by one every year I spend writing (and more importantly reading) code.

It should be immediately clear what any variable is for just by looking at a few lines of code. This can either be due to a nice variable name or the context.
About the only time I use short variable names is either if a short name is entirely descriptive (ie, x & y in a situation dealing with coordinates) or it's a utility function that operates on a data type (ie, capitalize the first letter of this string. It's a string, what else can you say about it? I named it S.)

I might not know what 'r' is later on in the code. Also, variable names are one thing, but you should be commenting code for the verbose explanation.
NB: This should probably be a community wiki as there's no definite answer.

This is bad. This is unmaintainable.
Short variables have their place. There is really no reason to write
for(int iterator; iterator
The rule of thumb is: One letter per screen of reach. With standarized 24 lines screen.
The exception is picking one-two extremely frequently used globals or semi-globals like pointer to the data storage or THE input data pointer, and make them 1-3 letters long. But anything else - use reason. Short loops - one letter. Locals of a function - 3-5 letters. Class variables - full word. Library class/function names - two words.

I don't see any reason to use short variable names that say nothing. We live in 21st century, we've got IDEs with IntelliSense (or other autocompletion)! Just press Ctrl+Space and it will advice you normal name for your variable depending on variable type, e.g.
StringBuilder <Ctrl+Space> stringBuilder;
List<Person> <Ctrl+Space> persons;
It is even easier than to type something like sb or another short name. No reason to use short names anymore.
P.S.: The only exception for me are counters like i, j, k in for loop.

I tend to prefer short "cryptic" variables (Symbols, in Mathematica) combined with descriptive comments.
Mathematica already has VeryLongFunctionNames for built in commands, and adding my own often spreads out code more than I care for.
I find it easier to read a shorter block of code where I can see everything at once, alongside a series of symbol descriptions.

Is it good form to expose derived values as properties?

I need to derive an important value given 7 potential inputs. Uncle Bob urges me to avoid functions with that many parameters, so I've extracted the class. All parameters now being properties, I'm left with a calculation method with no arguments.
“That”, I think, “could be a property, but I'm not sure if that's idiomatic C#.”
Should I expose the final result as a property, or as a method with no arguments? Would the average C# programmer find properties confusing or offensive? What about the Alt.Net crowd?
decimal consumption = calculator.GetConsumption(); // obviously derived
decimal consumption = calculator.Consumption; // not so obvious
If the latter: should I declare interim results as [private] properties, also? Thanks to heavy method extraction, I have several interim results. Many of these shouldn't be part of the public API. Some of them could be interesting, though, and my expressions would look cleaner if I could access them as properties:
decimal interim2 = this.ImportantInterimValue * otherval;
Happy Experiment Dept.:
While debugging my code in VS2008, I noticed that I kept hovering my mouse over the method calls that compute interim results, expecting a hover-over with their return value. After turning all methods into properties, I found that exposing interim results as properties greatly assisted debugging. I'm well pleased with that, but have lingering concerns about readability.
The interim value declarations look messier. The expressions, however, are easier to read without the brackets. I no longer feel compelled to start the method name with a verb. To contrast:
// Clean method declaration; compulsive verby name; callers need
// parenthesis despite lack of any arguments.
decimal DetermineImportantInterimValue() {
return this.DetermineOtherInterimValue() * this.SomeProperty;
}
// Messier property declaration; clean name; clean access syntax
decimal ImportantInterimValue {
get {
return this.OtherInterimValue * this.SomeProperty;
}
}
I should perhaps explain that I've been coding in Python for a decade. I've been left with a tendency to spend extra time making my code easier to call than to write. I'm not sure the Python community would regard this property-oriented style as acceptably “Pythonic”, however:
def determineImportantInterimValue(self):
"The usual way of doing it."
return self.determineOtherInterimValue() * self.someAttribute
importantInterimValue = property(
lambda self => self.otherInterimValue * self.someAttribute,
doc = "I'm not sure if this is Pythonic...")

The important question here seems to be this:
Which one produces more legible, maintainable code for you in the long run?
In my personal opinion, isolating the individual calculations as properties has a couple of distinct advantages over a single monolothic method call:
You can see the calculations as they're performed in the debugger, regardless of the class method you're in. This is a boon to productivity while you're debugging the class.
If the calculations are discrete, the properties will execute very quickly, which means (in my opinion), they observe the rules for property design. It's absurd to think that a guideline for design should be treated as a straightjacket. Remember: There is no silver bullet.
If the calculations are marked private or internal, they do not add unnecessary complexity to consumers of the class.
If all of the properties are discrete enough, compiler inlining may resolve the performance issues for you.
Finally, if the final method that returns your final calculation is far and away easier to maintain and understand because you can read it, that is an utterly compelling argument in and of itself.
One of the best things you can do is think for yourself and dare to challenge the preconceived One Size Fits All notions of our peers and predecessors. There are exceptions to every rule. This case may very well be one of them.
Postscript:
I do not believe that we should abandon standard property design in the vast majority of cases. But there are cases where deviating from The Standard(TM) is called for, because it makes sense to do so.

Personally, I would prefer if you make your public API as a method instead of property. Properties are supposed to be as 'fast' as possible in C#. More details on this discussion: Properties vs Methods
Internally, GetConsumption can use any number of private properties to arrive at the result, choice is yours.

I usually go by what the method or property will do. If it is something that is going to take a little time, I'll use a method. If it's very quick or has a very small number of operations going on behind the scenes, I'll make it a property.

I use to use methods to denote any action on the object or which changes the state of an object. so, in this case I would name the function as CalculateConsumption() which computes the values from other properties.

You say you are deriving a value from seven inputs, you have implemented seven properties, one for each input, and you have a property getter for the result. Some things you might want to consider are:
What happens if the caller fails to set one or more of the seven "input" properties? Does the result still make sense? Will an exception be thrown (e.g. divide by zero)?
In some cases the API may be less discoverable. If I must call a method that takes seven parameters, I know that I must supply all seven parameters to get the result. And if some of the parameters are optional, different overloads of the method make it clear which ones.
In contrast, it may not be so clear that I have to set seven properties before accessing the "result" property, and could be easy to forget one.
When you have a method with several parameters, you can more easily have richer validation. For example, you could throw an ArgumentException if "parameter A and parameter B are both null".
If you use properties for your inputs, each property will be set independently, so you can't perform the validation when the inputs are being set - only when the result property is being dereferenced, which may be less intuitive.

Overhead for not simplifying names in C#

I am working with a C# windows forms application (I doubt the project type affects answer but there it is anyways) and everything is going good. Code works fine. However Visual studio likes to tell me that Name can be simplified' when I do things like like usingthisin some methods where thethis` may not be needed. Here is an example:
public class xyz
{
string startdate;
string enddate;
private void calculateElapsedTime()
{
var endDate = Convert.ToDateTime(this.enddate).ToUniversalTime();
var startDate = Convert.ToDateTime(this.startdate).ToUniversalTime();
elapsedtime = (decimal)(endDate - startDate).TotalSeconds;
}
}
The names that can be simplified are this.startdateand this.enddate
The code runs fine without the this keyword but personally I like using the 'this' as for me it makes it more clear what is being done.
I tried running tests on memory usage and time if I go through and simplify all places where VS says I should and I ran the same test without simplifying names and got the same results.
So this has lead me to the question, Is there any actual performance hit for not simplifying names or is the hit so small that I just don't see the difference because my program isn't big enough or some third option?
EDIT
Since this is starting to get into a discussion on naming conventions figured I would add this. The above is a just an example of code that has a name that can be simplified not the actual way I write code. The name can be simplified message also would show up if you use the namespaceX.class.functionname in code already x namespace.

Is there any actual performance hit for not simplifying names or is the hit so small that I just don't see the difference because my program isn't big enough or some third option?
Not in the slightest. This is just a style choice that has no impact on the compiled code.
I would pick a different name for your local variables, though. Having the same name with just different casing on one letter makes it hard to distinguish between the local variable and the member name.

There will not be a difference in the performance or memory footprint of the application. Your C# code is translated into IL by the compiler, and that is the code that is executed - since the compiler understands both the version with this and without, the resulting IL will be identical in both cases, and as such so will the performance of the program.

You can like or not qualifying class member access with this, but since in C# is avoidable and one of most important premises in programming is keep as simple as possible, while it's just a coding style issue, it's still interesting that you understand that this in C# is used when you need to disambiguate an access to a local variable and a class member.
There's no performance hit and it's just about that you get used with C# coding style. For example, you use camel-casing on method identifiers while C# coding style says that they should be pascal-cased.
Like any other convention and guideline, it's just there to make your code more predictable to others rather than to yourself (and once you get used with these guidelines, they're also predictable for you too ;)).

BTW - the reason not to use this is because it makes you think that you dont need a naming convention for member variables.
Many people use a convention like
string _enddate
string endate_
string m_endate
that way you can tell by looking at the code that this is a member variable.
Using this.endate also says it is a member variable but the same code compiles if you just say enddate. Now you have code that compiles but you cannot tell at a glance if its a member or not