#1) If you press Ctrl+Shift+Enter after this at the end of an if-statement, it creates brackets. However, if your coding style is to have no brackets around a single-line if-statement, it would be more useful to allow Ctrl+Shift+Enter at the end of the first line of the if-statement.
Example:
if (shoppingCart == null)
return; <-- Ctrl+Shift+Enter here
Results in this:
if (shoppingCart == null)
{
return;
| <-- cursor here
}
Alternatively, some users may like to preserve the existing single-line statement as the LAST line.
Example:
if (shoppingCart == null) <-- Ctrl+Shift+Enter here
return;
Results in this:
if (shoppingCart == null)
{
| <-- cursor here
return;
}
#2) Support leading commas. This is a practice used with SQL. I also use it in regular code, as well.
Example:
private LineItemDetail CreateLineItem(IOrderLineItem lineItem)
{
return new LineItemDetail
{
ItemName = lineItem.Name ?? ""
,ItemSku = lineItem.SKU ?? ""
,LineItemId = lineItem.OrderLineItemID
,Quantity = (lineItem.Quantity == null) ? 0 : lineItem.Quantity.Value
,Description = lineItem.Description ?? ""
};
}
Running "Format Document" in Visual Studio results in this:
private LineItemDetail CreateLineItem(IOrderLineItem lineItem)
{
return new LineItemDetail
{
ItemName = lineItem.Name ?? ""
,
ItemSku = lineItem.SKU ?? ""
,
LineItemId = lineItem.OrderLineItemID
,
Quantity = (lineItem.Quantity == null) ? 0 : lineItem.Quantity.Value
,
Description = lineItem.Description ?? ""
};
}
Also, there is no way to convert trailing commas to leading commas, except to do it manually.
My favorite reason for using them is that they are very simple to add with column select. They speed up the copy, paste, modify approach that developers use everyday.
Here are a couple articles on the differences between trailing and leading commas:
http://ajaxian.com/archives/is-there-something-to-the-crazy-comma-first-style
http://www.thatjeffsmith.com/archive/2010/12/trailing-or-leading-commas/
#3) The keyword "this." should not necessarily be appended to class-level fields with an underscore. A common practice carried over from C++ is to use an underscore as the first character of a private field for a class.
Example:
public class OrderDetailCreator : IOrderDetailCreator
{
private readonly IShoppingCartHelper _cartHelper; <-- class-level variables are typically appended with an underscore. This tells you it is class level.
public OrderDetailCreator(IShoppingCartHelper cartHelper)
{
_cartHelper = cartHelper;
}
private void CheckCoupon(IShoppingCart shoppingCart)
{
bool isCouponValid = _cartHelper.HasValidCoupon(shoppingCart);
...
}
...
}
When using the C# --> Formatting Style --> Other --> Force "this." qualifier for instance member, with "For this class members"...
Then run "Format Document" in Visual Studio results in this:
...
bool isCouponValid = this._cartHelper.HasValidCoupon(shoppingCart);
...
However, this is redundant. If you are within the current class-level scope, the underscore already tells you it is class-level. "this." is verbose, redundant, and undesirable for such a common coding style.
So, why would would I choose to use this option, if it is just going to cause me problems?
2 reasons:
a) I want the properties to be "this.PropertyName".
b) If I am accessing a base class in the current class, I want to know it.
So, "base.field" or "base.PropertyName", since these come from a different scope.
And while finding "base._field" is an incorrect usage of "_variable", since it does not denote a private field, it is still common for developers to change the access level of a field/property without renaming it. This is also good to see, because it helps to tell you what needs refactoring.
This leads me to my next request...
#4) Allow for explicitly defining this. vs base.:
To me, "base" defines a member that is getting accessed from another class, and probably another file. But "this" is a more generic syntax for anything available in the local scope. So using "base." instead of "this." will tell you more about the location of the field/property without having to look at it. This can be an important piece of information when refactoring, as you may want to pull up a member, or move one down, without having to examine them to find where they exist. In my opinion, "this." is hiding "base.", which is information lost at worst, or ambiguous information at best.
