Best Practice: Declare Variables as Constants

In the bad old days, I only used constants as a way to assign names to values. Things like this, for example:

Private Const DaysInWeek As Integer = 7

However, these days most of my variables are holding objects; Some of my other variables are holding things like collections or delegates. That changes what we mean by "constant."

When a variable is declared as a constant, it doesn't mean that the object it's holding is immutable. You can, for example, still change values in the properties of an object held in a constant or add items to a collection held in a constant. It just means that you can't replace the object (or collection) that was assigned when the variable was initialized.

Especially in TypeScript (where many of my variables are holding functions), I'm switching to declaring my variables as constants. A subset of these variables are fields (class-level variables) that are set precisely once, in an object's constructor, and I'm taking the time to mark as those read only also.

If I want an actual immutable object I'll declare the object's properties as read only or use one of .NET's read only collections.

In part, I'm doing this because I'm thinking more in terms of value objects (an important concept in Domain Driven Design). However, there are other benefits. I'm told, for example, it makes life easier for the compiler. But it's also because this practice sends a clear message to the next developer (either using my code or modifying it) about how I think that the object should be used.

Posted by Peter Vogel on 02/12/2018 at 7:20 AM0 comments


Pasting Into a Command Window

I amazed a client recently who was looking over my shoulder when I copied a file path from the address in Windows Explorer.

Actually, it wasn't copying the path that impressed him -- it was when I pasted that text into a command window. I clicked in the command window, clicked on the icon at the right-hand end of the command window's title bar and, from the dropdown menu, selected Edit | Paste.

As the file path appeared in the window, he said "Now, that's cool."

This is how you get a reputation as wizard, kids. (I didn't say it was hard to do.)

Posted by Peter Vogel on 02/09/2018 at 6:20 AM0 comments


Load TypeScript Modules as You Need Them

In the bad old days you put all your JavaScript code into a single file and loaded that file on every page that needed any of your code. As the amount of JavaScript code increased, you started organizing your code into files and loading just the files you needed.

Currently, you can organize your code into modules and, for any particular module, specify what other modules it needs. Using a module loader, those other modules will automatically be loaded for you.

In the current version of TypeScript you can now load a module only if you actually need it. If you have a section of code that isn't always executed but requires some additional module support when it is used, then you can load that support dynamically at run time.

All you need to use is the import method, passing the relative path name to the file containing the module you need.

Of course, it will take a while for that file to be fetched and the module it contains made available. To handle that you can use the async and await keywords to make sure that you don't use that support until it's ready.

Typical code might look like this:

async function doSomethingAdHoc(): Promise<void> {
  if (userRequestedASpecialFunction) {
   await import('...relative path to JavaScript file...');
   ...do something...
  }
}

Posted by Peter Vogel on 02/08/2018 at 6:34 AM0 comments


Check That Your Config Files Are Transformed Correctly

Having a process to manage the settings in your application's Web.config file as you move from release to production is essential to ensuring your production Web site works correctly.

One way to handle that is to set up a Web.release.config file with transformation rules to convert your development config file to your production version whenever you compile in Release mode.

In Visual Studio, you can check to see if that transformation is doing what you want by right-clicking on the Web.release.config file in Solution Explorer and then selecting Preview Transformation from the popup menu. Selecting Preview Transformation will open a window with two panes; the pane on the left shows your original file, while the pane on the right shows your transformed version.

Any lines that are modified, added or deleted are automatically highlighted in both panes, making it easy to see what changes will be made. You don't even have to go looking for the changes, either: There's a bar down the right side of the window, flagging where in your config file you'll find your changed lines.

Do be careful, though: It's possible to write your transformation so it doesn't find the part of your config file it's supposed to transform and, as a result, no transformation is made. Other than the absence of a change (something that's hard to notice), there's nothing in the preview to flag that your transformation has failed.

Posted by Peter Vogel on 01/05/2018 at 10:04 AM0 comments


Shrink Your Visual Studio Window (and Put it Back)

I suspect I'm like most developers and keep Visual Studio open and maximized all day (in fact, I've written at least one tip about how to get even more room to edit code). But, I admit, sometimes I switch to other programs. And sometimes, when switching between windows isn't good enough, I need to see that other window beside my Visual Studio window.

You could fiddle with your mouse and window borders. Or, you could hold down the Windows key and press the left arrow button (win_left). The current window will be moved to one side of your screen, have its height set to the full height of your screen and its width set to half of the screen's width. If you switch to another window and press win_left the same thing will happen to that window -- but it will be moved to the other side of your screen so that the two windows display side-by-side. If a window was in maximize mode, it will be taken out of it.

As you might suspect, other combinations of the Windows key and the arrow keys do interesting things. If you press win_up, the current window will be maximized. Both win_right and win_down take the window back to its prior "non-maximized" state (and that half-window display that win_left put you in doesn't count as your prior "non-maximized" state).

And, yes, I realize this isn't really a Visual Studio tip since it works with every window.

Posted by Peter Vogel on 07/30/2015 at 2:20 PM0 comments


Keeping Debugging Data on the Screen

I admit it: I don't use the Watch window much. When I hit a breakpoint and want to know what the current value is in a variable that's near the breakpoint, I'll either type "?variableName" in the Immediate window or hover my mouse over the variable to have Visual Studio pop up a Data Tip with the variable name and value.

If you're a "hover your mouse" kind of person you should pay attention to the pushpin at the end of the Data Tip: If you click on the pushpin and switch it to the "upright" position, that Data Tip will stay on the screen. The next time you hit the breakpoint (actually, whenever you have that part of your code on the screen) the Data Tip will be there, displaying the current value of the variable. If you need to drill down into the variable, you can use the plus sign (+) at the beginning of the Data Tip to see the values on the item's properties.

You can do more with your Data Tip: When you hover your mouse over the Data Tip, a "mini-menu" of choices will appear just past the end of the Data Tip. The middle icon in this mini-menu will let you unpin the tip which does not, as you might expect, cause the tip to disappear. Instead, the tip just drifts off to the right and now appears whenever you hit a breakpoint in any code window. This can be very helpful when you're trying to check one variable's value against another or want to change the value of the variable in the Data Tip. The bottom option in the mini-menu, which lets you leave a comment to yourself, can also be useful if your memory is as bad as mine.

The Debug menu also has some choices for managing Data Tips (including exporting and importing Data Tips if you want to keep some around after your debugging session ends). Data Tips are not an unalloyed blessing, if you have long variable names (names are usually displayed with their complete namespace): If the name disappears off the right side of your screen you won't get a scroll bar that will let you move to the right.

Posted by Peter Vogel on 07/23/2015 at 2:20 PM0 comments


What's New in Visual Basic 14 for Visual Studio 2015

Let me start with the most trivial change that's also the one you'll use the most: Right now, you type in a line of code, get a squiggly line under something indicating that you've got an error, fix the error … and then arrow off the line to see if the squiggle goes away. In Visual Studio 2015 with Visual Basic 14, you won't have to move off the line to have the squiggle go away: It will just go away.

The change you'll like best: You can view the results of a Lambda expression in Debug mode instead of getting that stupid "Evaluation of lambda expressions in this debugger" message.

Well, maybe you'll like this best: Shorter error messages in the Error List window. The Error List window, instead of showing variable names with all of their namespace prefixes, will now just use the base variable name. Your error messages might actually now fit in the Error List window.

The most important change that you should use more: Refactoring. Out of the box, C# developers have always had more refactoring support (encapsulating fields, for example) than Visual Basic developers. Now Visual Basic 14 developers get parity: select some code, right-click and select Quick Actions. A light bulb menu appears with all (and only) appropriate refactorings you can apply to the selected code.

The one you won't need very often but will really like when you do use it: Shared Projects. You can use a project's resources (source code, images, and the like) in other multiple projects.

And, finally, the one that will save you the most time: Your Visual Basic code should compile in half the time. Half. The. Time.

Posted by Peter Vogel on 05/20/2015 at 1:44 PM0 comments


Configuring for a Setup Project

Eventually, it comes time to transfer your project to the production or quality assurance (QA) computer. In theory, you should just need to copy some files to the other computer. In practice, it's a lot safer to create a setup project that packages up everything you need and unpackages it on the other computer.

You do want to rebuild your setup project every time you're going to release your application; you don't need to rebuild your setup project every time you build your application. The difference between when you need to rebuild your setup project and when you don't comes down to your compile mode: Are you compiling in release mode or debug mode?

When you're working on your application, you want to compile in debug mode so that you can step through your code; when you're ready to release your application (even if it's just to the QA computer), you'll want to compile in release mode so that you get all the optimizations possible. It's only in release mode that you'll need to rebuild your setup project.

You can get Visual Studio to take care of this for you: Go to Visual Studio's Build menu and select the Configuration Manager choice. In the upper left hand corner of the resulting dialog, you'll see a dropdown list set to Debug. This indicates that the settings being displayed are the ones applied during a debug compile. Find your setup project in the list in the bottom part of the dialog and uncheck the checkbox in the Build column (you should also pick a setting for how your setup project is to be built in the Configuration column).

With your Debug settings in place, switch the dropdown list from Debug to Release. After this change, make sure that the Build option for your setup project is checked (you could also uncheck the Build option for your test project because you probably don't need to rebuild it for a release mode compile). With your release mode settings made, click the Close button to save your changes and you're done.

From now on, you just have to remember to switch the dropdown list in Visual Studio's toolbar from Debug to Release when you need a new version of your setup project (and switch the list back to Debug immediately after you generate the setup project so that you get debugging support in your compiles).

Posted by Peter Vogel on 03/19/2015 at 2:20 PM0 comments


Restricting Columns Retrieved in Entity Framework

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/2014 at 1:51 PM0 comments


Best Tip. Ever: Change Your Visual Studio Development Default

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:

  1. From the Visual Studio Tools menu, select Import and Export Settings to open the Import and Export Settings wizard.
  2. In the first panel of the wizard, select the Import selected environment settings option. Click the Next button.
  3. Select No, just import settings option and click the Next button.
  4. On the Choose a Collection of Settings to Import page of the wizard, select the settings you want. Click the Next button.
  5. 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/2014 at 1:51 PM0 comments


Files and Classes: Organize by Use

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/2014 at 1:51 PM0 comments


Write to Visual Studio's Output Window on Your Breakpoints

I can't tell you the number of times I've put a breakpoint inside a loop so that I could stop each time I go through the loop and check the value of some variable or property. Unfortunately, by the third or fourth trip through the loop I've forgotten what the values were on my first trip through the loop.

If that's your life also, your best choice is to use a tracepoint which will write the information you're interested in to the output window. With a tracepoint, you can review the values you're interested in after the loop finishes. You can even just let your code run, rather than stopping on the line you're interested in.

Setting a tracepoint varies from one version of Visual Studio to another. The easiest way is to set a breakpoint and then right click on the dot in the margin that marks your breakpoint. When the popup menu appears, either select the When Hit choice (in earlier versions of Visual Studio) or the Actions choice (in later versions). Those choices will display the dialog that lets you define your tracepoint.

In that dialog you can enter the message you want written to the output window, enclosing any variables you want displayed in curly braces ({ }). Something like "The counter is {i} and the Customer's age is {cust.age}" will work, for example.

If you'd rather not stop on the breakpoint, make sure the Continue Execution checkbox at the bottom of the dialog is checked. You can do a quick visual check to see if you'll be stopping on the line: If you still have a dot in the margin, it's still a breakpoint and you'll stop every time the line is hit; if you have a diamond in the margin, it's a tracepoint and will just write out your message without pausing.

Now run your application and, after it finishes, look in the output window to see how your data changed over time.

Posted by Peter Vogel on 06/23/2016 at 10:52 AM0 comments


.NET Insight

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.

Upcoming Events