You copy something in Visual Studio and, before you can paste it you realize that you need to copy something else. Or, worse, you copy something, forget what you're doing, copy something else, go to paste ... and realize that you've lost that first thing you wanted.
Good news! The Visual Studio clipboard actually remembers the last 20 things you cut or copied. To access that history, instead of pressing Ctrl_V to paste your item, just press Shift+Ctl+V. The first time you press that combination you'll paste the last thing you cut or copied; the second time you press it, you'll paste the second last thing you copied right over top of the first item; the third time you press it ... you get the picture.
This feature even works if you press Ctl+V the first time. So, if you paste something you don't want, just switch to Shift+Ctl+V. The first press will get you what you just pasted but your second press will start working you back through your "copy history."
So, go ahead and copy that other thing -- you'll be able to get back to the item currently sitting in the clipboard when you need it.
Posted by Peter Vogel on 12/11/20140 comments
I was having an e-mail exchange with a reader who commented that he was having trouble following my coding conventions. Among other issues, I seemed to arbitrarily capitalize variable names. I explained that, in these columns, I specifically varied my coding conventions from article to article, just to avoid looking like I'm endorsing any particular style (one of the reasons that I don't use C# in most of my columns is I'm a "every curly brace on its own line" kind of guy and I don't want to get into an argument about it).
You can probably assume that anything you see that does turn up regularly in these columns is there because I think it's mandated by Visual Studio Magazine.
But there's another reason for the variation you see: Often the code in these columns is drawn from projects that I'm doing for a client and, since I've just copied the code and obfuscated its origin, the code reflects my client's coding conventions. And that made me notice something: As I move from client to client, I keep changing my coding conventons and, you know what? All the coding conventions I use seem good to me. And that, in turn, got me thinking: What does matter in a coding convention?
There's actually some research around this, if you're interested. The earliest work, I think, is in Gerald Weinberg's The Psychology of Computer Programming but the most complete review I know of is in Steve McConnell's Code Complete.
It turns out that the only thing that makes a difference is consistency (or, if you prefer, simplicity). The more special cases and exceptions that a set of coding conventions include, the more likely it is that the conventions won't be followed correctly by programmers writing the code or won't be understood by programmers reading the code.
The most successful coding conventions (the ones that programmers comply with, implement correctly, and find useful when reading code) are short and have no exceptions. As an example, the Microsoft C# Coding Conventions would probably cover three pages if printed out (and less than a page if you omitted the examples). Given the research available, that seems about right.
Posted by Peter Vogel on 12/09/20140 comments
I think everybody knows that if you click on a variable, method, or property name and press F12 (or select Go To Definition from the pop-up menu) you'll be taken to the method or property's code or to the variable's declaration. But sometimes you want to see the reverse: All the places where a property, method, or variable is being used -- and not everyone seems to know about that.
That's too bad because it's a cool feature of Visual Studio: Just click on a method (or property or variable), press Shift+F12 (or select Find All References) and Visual Studio opens a new window below the editor window, listing all the places where the method is used. If you double-click on one of the items in the list, you'll be taken to the code. With that list, therefore, you can step through all the places in your application that you might want to look at to understand how the method is used (the definition of the method appears at the top of the list, by the way, so you can go there, also).
The Window stays visible until you close it or do something that moves another window in the group to the top (building your application pops the output window over the list, for example). The Window is still there if you want to go back to it, however: It's called Find Symbol Results.
Posted by Peter Vogel on 12/04/20140 comments
A couple of months ago, I wrote a column on how to avoid downloading columns in a table that has hundreds of columns or columns containing large objects (or, at least, only downloading those columns when you want them). But that solution only makes sense when getting the columns you want is something that you'll be doing frequently.
If, on the other hand, you have exactly one place in your application where all you want to get is, for example, the Customer's first and last names then there's a simpler solution: Just define a class that has the columns you want.
Two caveats: First, you can't do updates through the objects you've retrieved using this technique. Second, don't expect to get a huge performance gain from this unless you're avoiding retrieving many other columns or the columns you're avoiding are blob columns.
As an example, to get the Customer's first and last name columns I'd begin by defining a class, outside of my Entity Framework model, to hold just those columns:
Public Class CustFirstLastName
Public Property FirstName As String
Public Property LastName As String
End Class
Now, I write a LINQ query to retrieve just those two columns by instantiating the class in my LINQ statement's Select clause and setting its properties with values retrieved through Entity Framework. This code assumes that my DbContext object (in the db variable in this example) has a collection called Customers:
Dim lastFirstNames = From c In db.Customers
Select New CustFirstLastName With {
.FirstName = c.FirstName,
.LastName = c.LastName
}
The SQL generated by Entity Framework to get the data from the database will just grab the FirstName and LastName columns because that's all that's been used in the Select statement.
If you're new to Entity Framework, you probably consider this obvious -- that's what EF should do. But, in the early days of EF, this wasn't the behavior you got: EF always retrieved all the rows specified in the entity class (in this case, whatever class makes up that Customers collection). EF's gotten smarter since then and you can take advantage of it.
But, as I said, my CustFirstLastName class is not part of my entity model. If I make changes to the CustFirstLastName object's properties and call my DbContext object's SaveChanges method those changes will not be transferred back to the database. To update the database, I need to make my changes to whatever objects are in the Customers collection in my sample code.
Posted by Peter Vogel on 12/02/20140 comments
I know that I keep going on about this, but: The best way to speed up your application is to retrieve all the data you need on each trip to the database and make as few trips to your database as you can. One way to do that when retrieving rows is to retrieve multiple sets of rows on each trip.
This means that you can reduce trips to the database in a stored procedure, by returning multiple sets of rows from a single stored procedure with a single call. If you're using ADO.NET, you can combine multiple Select statements in your Command object's CommandText property (just make sure you put a semicolon between the statements):
Dim cmd As New SqlCommand
cmd.CommandText = "Select * from Customers; Select * from Countries;"
When you call ExecuteDataReader to get your DataReader, the DataReader will be processing the first set of records returned from your stored procedure or from the first Select statement in your CommandText:
Dim rdr As SqlDataReader
'Processing customers
rdr = cmd.ExecuteReader()
You can process that recordset or not -- your choice. When you're ready to process the next set of rows, just call DataReader's NextResult method. This command moves the DataReader to process the Countries that I retrieved:
rdr.NextResult
Because of the way that ADO.NET talks to your backend database will vary from one database engine to another and on how much data you're retrieving, I can't guarantee that each NextResult won't trigger another trip to the database (ideally, all of the data will come down to the client in one trip).
But you're guaranteed that you'll only make one trip to the database when you make the initial request and that's a good thing.
And, as I mentioned in another tip, if you want to mix some update commands in with your Select statements, you can do that, too -- saving you even more trips. I wouldn't suggest that combining these tips eliminates the need for stored procedures; I would, however, suggest that you only use stored procedures when you need some control logic mixed in with your SQL statements.
Posted by Peter Vogel on 11/20/20140 comments
In the bad old days, when an application threw an exception, we frequently extracted the system-generated message and put it on the screen for the user to read. Often it included information that we'd prefer not to share with the outside world (table names and details of the connection string, for instance).
A better practice is to generate an application-specific message that reveals just what you want. And, unlike most system messages that describe what's wrong, your message could tell the user something useful: what to do to solve the problem. A unique message will also help you identify where things have gone wrong in your application. The right answer is to create your own Exception object with a unique message:
Try
...code...
Catch Ex As Exception
Throw New Exception("Something has gone horribly wrong")
End Try
However, when you're debugging, the information you need to prevent the exception from happening again is in the original exception object.
As some readers pointed out to me in comments to an earlier tip, the right answer is to pass the original exception as the second parameter to the Exception object's constructor. Enhancing my earlier code, the result looks like this:
Try
...code...
Catch Ex As Exception
Throw New Exception("Something has gone horribly wrong", Ex)
End Try
The Exception object you pass as the second parameter will show up in the InnerException property of the Exception object you're creating.
Posted by Peter Vogel on 11/13/20140 comments
When you installed Visual Studio, you picked a group of default settings, primarily driven by what language you intended to use (C#, Visual Basic, etc.).
The odds are that you'll never need to change those settings ... but it does happen. If, for example, your company changes from Visual Basic to C#, you'll find that all of your C# project templates are buried under Other Project Types.
Here are the steps to change your settings:
- From the Visual Studio Tools menu, select Import and Export Settings to open the Import and Export Settings wizard.
-
In the first panel of the wizard, select the Import selected environment settings option. Click the Next button.
-
Select No, just import settings option and click the Next button.
-
On the Choose a Collection of Settings to Import page of the wizard, select the settings you want. Click the Next button.
-
On the final page of the wizard, click the Finish button, the OK button on any warning dialogs, and the Close button on the final page of the wizard.
It's as easy as that.
Posted by Peter Vogel on 11/06/20140 comments
In an earlier column, I referenced using TransactionScope instead of the ADO.NET Transaction object. The problem with an ADO.NET Transaction object is that it must be associated with each ADO.NET Command object that's involved in the transaction. In addition, all of those Command objects must use the same Connection object. If those Command objects are spread over multiple methods, then you end up having to pass the Transaction object to each method. And, unless you've declared your Connection object globally (not a great idea), you'll also have to pass the Connection to those methods.
For example, you end up writing code like this:
Try
Dim trans As SqlTransaction
Dim cn As new SqlConnection("…")
Dim cmdNewClaim As SqlCommand = New SqlCommand("…")
cmdNewClaim.CommandType = CommandType.StoredProcedure
cmdNewClaim.Connection = cn
cmdNewClaim.Transaction = trans
cmdNewClaim.ExecuteNonQuery()
GetRecordOwner(processableInvoices.First.RecordOwner, cn, trans)
trans.Commit
Catch Ex As Exception
trans.Rollback
End Try
Using TransactionScope simplifies this code tremendously by enclosing every ADO.NET call within a transaction -- even when the call is inside another method. You need to add a reference to System.Transactions and include an Imports/Using statement for System.Transactions. Wrapping the previous code in TranscationSocpe object declared in a using block eliminates some lines of code and simplifies the call to the enclosed method. You don't need to include a rollback call because if the code reaches the end of the Using block without a call to Complete, your transaction is automatically rolled back:
Using trns As TransactionScope = New TransactionScope
Try
Dim cn As new SqlConnection("…")
Dim cmdNewClaim As SqlCommand = New SqlCommand("…")
cmdNewClaim.CommandType = CommandType.StoredProcedure
cmdNewClaim.Connection = cn
cmdNewClaim.ExecuteNonQuery()
GetRecordOwner(processableInvoices.First.RecordOwner)
trns.Complete
End Using
As an extra benefit, if the enclosed method uses a different connection, the connection should be automatically elevated to a distributed transaction.
Posted by Peter Vogel on 11/03/20140 comments
The slowest thing you can do in your application is read or write to your hard disk.
The second slowest thing you can do is issue a request to another computer. This means, of course, that whenever you access your database you're doing the two slowest things you can manage. Which means that one of the simplest things you can do to speed up your application is to reduce the number of trips you make to your database, even if you don't make any changes to the amount of data you update or retrieve.
Imagine, for instance, you have this code that first adds a record and then retrieves the number of records present after the insert:
cmd.CommandText = "Insert Into ... ;"
cmd.ExecuteNonQuery()
cmd2.CommandText = "Select Count(*) from ... ;"
Dim res As Integer
res = cmd.ExecuteScalar()
As it's written, this is going to involve two trips to the database. There's no reason, however, that the two SQL commands can't be combined into a single request, executed by calling ExecuteScalar:
cmd.CommandText = "Insert Into ...;" & "Select Count(*) from ...;"
Dim res As Integer
res = cmd.ExecuteScalar()
Part of the problem is that the ADO.NET method names (ExecuteReader, ExecuteScalar and ExecuteNonQuery) suggest there's only one kind of SQL statement you can use with any method. But, in fact, the three method names really reflect what's returned: ExecuteReader returns a DataReader that will let you work through the rows returned by a Select statement, ExecuteScalar returns the first column of the first row returned by a Select, and ExecuteNonQuery returns the number of rows updated.
You're free to pass any kind of SQL statement (or combination of SQL statements) to any of these methods and it will probably work out for you. If you need, for example, to issue some updates and then retrieve the results, then combine your Update/Insert/Delete statements with a Select statement, execute the commands with a call to ExecuteReader and then use the resulting DataReader to process the rows you get back.
Posted by Peter Vogel on 10/10/20140 comments
The default organization method Visual Studio uses when adding classes is to put each class in a separate file. That doesn't mean you should do the same thing. This is especially true in Visual Studio 2012, which combines Class View with the Solution Explorer standard File View (and adds a search capability on top of that).
Even in earlier versions of Visual Studio, you can always get to a class's code just by clicking on the class name in your code and pressing F12. With those tools in place, it's hard to see much advantage in being able to scroll to the class file in the Solution Explorer file view. Keeping each class in a separate file is an option, not a requirement.
Off the top of my head, I can think of at least two occasions where it makes sense to put multiple classes in the same file. First, where you have a class that's used only by one other class, it's probably easier for everybody if you keep those two classes in a single file. Second, EventArgs classes that are generated in one class and returned from that class's events might be best kept in the same file with the class that generates it.
I bet some of you can think of other occasions where it makes more sense to put two classes in the same file than it does to put them in separate files. That's OK.
Posted by Peter Vogel on 10/07/20140 comments
I've admitted it before: Regular expressions defeat me.
NimbleText gives me an editor and an "English-like" way of writing templates that will convert a list of data values into something more useful. Under the hood, it uses regular expressions to identify the data to change but I'm insulated from that. NimbleText isn't a Visual Studio add-in so you have to leave Visual Studio to use it, but even with that limitation NimbleText lets you do wonderful things.
NimbleText is relatively user-friendly: It's well-documented and has menus for selecting and inserting NimbleText keywords into your templates (though many of my templates don't need them). More importantly, NimbleText has a library of snippets to help get you started.
This snippet, for instance, integrates NimbleText keywords and JavaScript to generate C# properties from a list of datatypes and property names:
<% $0.toLowerCase() %>private $0 <% $1.toCamelCase() %>;
$ONCE
$EACH
public $0 <% $1.toPascalCase() %> {
get { return <% $1.toCamelCase() %>; }
set { <% $1.toCamelCase() %> = value; }
}
I've also used NimbleText to process text files of data (eliminating duplicate rows, for instance). I can't tell you that the learning curve is zero, but it's pretty darn flat.
Posted by Peter Vogel on 10/02/20140 comments
In a tip from a couple of months ago, I suggested that if you have a method or property that returns a collection, then your method should return only one of three interfaces: IList, IQueryable or IEnumerable. (Returning an interface allows you to change the type of the collection used inside your method without breaking the clients that use your method.)
Not surprisingly, I got some interesting feedback from readers. One reader pointed out that if you're going to allow the client to update your collection, Microsoft recommends your method return ICollection. ICollection allows the client to add to the end of your collection, to clear your collection, and to remove specific objects from the collection; ICollection doesn't allow the client to insert or delete items at specific positions in your collection. In other words, ICollection allows the client to update the collection you return only by adding to it or by removing specific objects. I can see how that could be a better choice than IList, which allows the client to arbitrarily insert and remove items by position.
Side note: Interestingly, neither ICollection or IList supports one of my favorite methods, AddRange, which allows you to add a collection of items to the end of another collection (AddRange is only available on the List class itself). I'm fond enough of AddRange that I've created my own extension method that adds the method to any class that implements IList. I'll switch that extension method's definition over to using ICollection.
No one objected to my recommendation for using IQueryable with methods that return Entity Framework results. However, I realized I was being narrow-minded. You should use IQueryable to return the result of any LINQ query where you want to give the client the ability to extend the query by using the result in another LINQ query (this gives the compiler more options in optimizing the final query). That's going to be an Entity Framework result 90 percent of the time, but I should be as inclusive as possible.
However, another reader did suggest that, if you were only going to let the client read your collection, IReadOnlyList is a better choice than IEnumerable. Just like IEnumerable, IReadOnlyList allows the client to retrieve items at specific locations and to build For…Each loops to process the list. Declaring your method as returning IReadOnlyList does have the advantage of being more obvious than IEnumerable in communicating that your collection is read-only, though. Unfortunately, IReadOnlyList is only available in the Microsoft .NET Framework 4.5 and newer.
So here's the latest and greatest version of my advice: If your method or property is returning a collection and you want to allow the client to add or remove objects in a controlled way (add only at the end, remove only by object reference), return ICollection; if you want to give the client the ability to work with the items in your collection by position, return IList. If you're returning the results of a LINQ query and want to give the client the ability to use the result in another LINQ query in an efficient way, use IQueryable. For everything else (which just leaves read-only collections) use IReadOnlyList; if IReadOnlyList isn't available, use IEnumerable.
Posted by Peter Vogel on 09/23/20140 comments