Feature Requests and Changes Follow
#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.
Please sign in to leave a comment.
Personally, I find leading commas slow down this approach.
For example, try moving the first property assignment to the end with leading commas:
And with trailing commas:
With leading commas, you get two lines with a syntax error which you have to correct; with trailing commas, it just works.
I agree that, with leading commas, moving the first line is the biggest pain point.
The best way to comma separate is case-by-case.
If I have 3 simple strings:
"hi"
"yo"
"go"
... then all 3 are easy, no matter your approach.
If I have 3 variable length strings:
"hi"
"cowboy rollercoaster park"
"kung fu fighting"
... then, in my opinion, using a column select to insert a comma at the beginning is clearly faster:
"hi"
|"cowboy rollercoaster park"
|"kung fu fighting"
"hi"
,"cowboy rollercoaster park"
,"kung fu fighting"
Certain text editors make this process easier, like Sublime, where you can select the end of every line and modify them at the same time. However, this feature has not made it into Visual Studio, yet, to my knowledge. If it does, trailing commas would be less annoying. PSPad has an interesting feature where you can add text to the beginning and end of the line. A friend of mine also uses AutoHotKey to manage his comma separated lists. I find leading commas to be simple to manage and debug, particularly as lines grow off the screen.