Explicit “this” #
I prefer an explicit “this” when referencing instance members locally.
StyleCop classifies this as a readability rule, with the following notes in the description:
A violation of this rule occurs whenever the code contains a call to an instance member of the local class or a base class which is not prefixed with ‘this.’. An exception to this rule occurs when there is a local override of a base class member, and the code intends to call the base class member directly, bypassing the local override. In this case the call can be prefixed with ‘base.’ rather than ‘this.’.
By default, StyleCop disallows the use of underscores or m_ to mark local class fields, in favor of the ‘this.’ prefix. The advantage of using ‘this.’ is that it applies equally to all element types including methods, properties, etc., and not just fields, making all calls to class members instantly recognizable, regardless of which editor is being used to view the code. Another advantage is that it creates a quick, recognizable differentiation between instance members and static members, which are not prefixed.
A final advantage of using the ‘this.’ prefix is that typing this. will cause Visual Studio to show the IntelliSense popup, making it quick and easy for the developer to choose the class member to call.
https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/documentation/SA1101.md
Adding to the above, I think it increases code clarity, especially when reading things like differences in pull requests. Sometimes you’ll only see the changed code with little context, and “this” can make it clear what’s being referenced.
In addition, I like that starting local calls with this. gives me an easy place to align multi-line statements, which also increases readability. For example:
this.Context.SomeTable
.AsNoTracking()
.Where(x => x.Id == id)
.OrderBy(x => x.FirstName)
.Select(x => x.FullName)
.Skip(10)
.Take(10)
.ToList();
Tabs vs Spaces #
My position on tabs vs spaces is: tabs for indentation, spaces for alignment.
public class Example
{
|--|public void Method()
|--|{
|--||--|this.Property
|--||--| .DoSomething()
|--||--| .DoSomethingElse();
|--|}
}
It reads the same no matter your tab width #
I like a 4-space tab. Some people like 2-space. Maybe there are some crazies out there that like an 8-space tab. Using tabs for indentation means everyone can be happy with no changes to the source. Using spaces forces everyone to agree on a tab size.
It’s explicit #
Blocks are clearly defined by tabs with no ambiguity. It’s good to be explicit.
It’s easier to work with #
Adding indentation is easy either way – hit the tab key – but removing tabs is more work with spaces. IDEs will handle a lot of this work, but if you ever end up editing something without that assist, you’ll save keystrokes with tabs. I also find tabs generally easier to navigate for the same reason. One level of indentation is one left or right keystroke. (You can use ctrl+right, but that can be inconsistent.)