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


Get Back to the Visual Studio Editor Window Without the Mouse

So your mouse is in some tool pane in Visual Studio and you want to get back to the editor window. You don't have to reach for the mouse -- just press the Escape key. You may have to press the key multiple times but sooner or later, your cursor will probably end up in the editor window. I have to say "probably" because, every once in a while, using Escape won't get you back to the editor window.

To make up for that uncertainty, here's another tip: Once you're back in the editor window, if the current document isn't the one you want, you still don't have to reach for the mouse -- just press Ctrl+F6 to cycle through the currently open documents.

Posted by Peter Vogel on 11/18/2016 at 12:33 PM0 comments


Add a Shortcut to Frequently Visited Code

I had an application with one section I had to work on every couple of months over several years (the client kept changing its collective minds about how it wanted part of the UI -- a search page -- to work). Eventually, I created a shortcut to the section of code I kept having to change so that I could get there quickly. Adding a shortcut is just one step: Click on a line and type Ctrl+K+H.

Returning to that line requires two steps: First, in any version of Visual Studio, you select Task List from the View menu. After that, though, getting to the list of shortcuts depends on which version of Visual Studio you're using. On some versions, you have a dropdown list underneath the title bar in the Task List -- selecting Shortcuts from that dropdown list lets you see your shortcuts.

If, on the other hand, there is no dropdown list, shortcuts appear mixed in with other Task List items. Either way, once you have the list displayed, you navigate to your selected area by double-clicking on its shortcut in the Task List.

As with any other Task List item, you can't delete a shortcut from within the Task List. If you don't want to keep that shortcut around anymore then you'll need to go to that line of code, click somewhere in it and use Ctrl+K+H again to remove the shortcut.

Posted by Peter Vogel on 10/07/2016 at 1:27 PM0 comments


Suppress Columns in Entity Framework Code-First

I'm not a big fan of what I call "aggressive code-first," where your table design is derived from your object design. And, to tell you the truth, I'm not sure I have a good reason for my skepticism. With the one client I worked for who used this process, everything worked out fine (by which I mean that the table design we ended up with was exactly the one I would have recommended).

One issue I have with deriving my table design from my object model is that my object model frequently includes properties that I don't want to have appear as columns in my database. The most obvious example of this are read-only properties whose values are calculated internally (typically, from other properties on the object). Entity Framework is smart enough that it will skip most of these properties but, every once in a while, EF will want to add a column to a table based on a property that I'd prefer EF ignored.

To get EF to ignore the property, just decorate the property with the NotMapped attribute. In this code, for example:

Public Class Customer
  Public Property Status As String
  Public Property Rating As String
  <NotMapped>
  Public Property CreditRating As String
End Class

the Customer class' Status and Rating properties will generate columns in the Customer table but the CreditRating property will not.

Posted by Peter Vogel on 09/30/2016 at 2:18 PM0 comments


Label Your Breakpoints

With more recent versions of Visual Studio, breakpoints you set in your code are saved from one editing session to another. Because you might not always want to stop on those breakpoints, however, you will want to selectively enable and disable them. To facilitate that, from the Debug | Windows menu choice, open the Breakpoints window to view (and manage) all of your breakpoints. From this window you can, for example, double-click on any of the listed breakpoints to be taken to its position in your source code.

The only problem is that, in the Breakpoints window, all breakpoints look very much alike. Fortunately, once you're in that window, you'll also find that you can right-click on any breakpoint and assign it a label that's displayed right beside the breakpoint in the window (you can also right-click on the breakpoint in your source code and assign a label right there). If you're clever about adopting a naming convention you can then sort your breakpoints into groups that you can enable and disable with a single click just by selecting multiple breakpoints in the window. There's no reason, for example, that you can't assign one label to a set of related breakpoints.

There's more you can do in this window. You can assign a condition specifying when the breakpoint should be honored or have the breakpoint write a message to the output window instead of stopping on the breakpoint. You should start thinking of your breakpoints as a resource that lasts the life of your code.

Posted by Peter Vogel on 09/26/2016 at 11:52 PM0 comments


Doing Calculations Right with the Math Class

The .NET Framework gives you the Math class, which has a ton of methods and properties that you can use.

The Abs function will convert negative numbers to positive (and leave positive numbers alone), while the Sign method will tell you if a number is positive, negative or zero.

The Truncate, Ceiling, Floor and Round methods will give you four different ways to get the integer portion of a decimal value, depending on what you want.

The DivRem method will return both the result of a division and its remainder (and IEEERemainder has a special result when you divide a smaller number by a larger number).

The Math object's PI property gives you a value of PI to more than 12 decimals -- more accuracy than you'll probably need.

The Sin, Cos and related methods will perform all of those trigonometry functions that I never really got in high school.

There's more functionality here than I can discuss, but I have to mention the BigMul method (which sounds like the name of a Scottish folk hero to me). When you multiply two large integer numbers you might get a result bigger than an integer … which will cause an overflow exception. BigMul, on the other hand, will multiply two 32-bit integers and return a Long, avoiding overflow.

Maybe it is a folk hero.

Posted by Peter Vogel on 09/15/2016 at 8:19 PM0 comments


Always Go to Production in Release Mode

I was at a client's site recently and watched them move the new version of their app to production by copying all the DLLs from the "staging" computer to the production computer. I commented on how that was the beauty of the .NET Framework: Once you had the application installed, upgrades could just consist of replacing the EXEs and DLLs. Of course, I added, you have to remember to do one last compile in Release mode before copying the DLLs.

My client said, "Pardon?" I said, "What!?!"

It turns out that, at my client's site, once a developer got their code working, my client just copied that developer's DLLs to the QA testing site. There's nothing wrong with that ... but my client was leaving money on the table as far as performance goes.

When you press F5 to start debugging, Visual Studio saves and compiles your application. However, that compile is a "fast and sloppy" one -- Visual Studio doesn't do any real optimization of your code. There are a couple of reasons for that. First, this "fast and sloppy" compile gets you into debug mode faster (which is good). Second, skipping optimization avoids rearranging, merging or even eliminating lines of your code, which some compiler optimizations can do. When you're stepping through your source code in debug mode, it's helpful if there's a one-to-one relationship between your source code and your compiled code which rearranging/merging/eliminating makes difficult.

However, when you move to production, you want all of those optimizations. I know that I've said elsewhere that the speed of business applications is controlled by their data access ... but for the cost of going up to the toolbar and changing that Solution Configuration's dropdown list setting from Debug to Release you can, potentially, get a significant improvement in your application's performance (my client estimated about a 10 percent reduction in average response time, for example).

You do have to remember to switch back to Debug mode after doing your "production compile." One of the other things that the Debug mode does is generate a .pdb file that supports debugging (among other things, it provides the relationship between your lines of source code and your compiled code). If you don't keep regenerating that file as you make changes to your source code, your debugging sessions will get decidedly weird.

Posted by Peter Vogel on 09/09/2016 at 11:54 AM0 comments


Maximize Your Visual Studio Editor Window Space Fast

When I'm writing code, I like to devote as much screen space in Visual Studio to my editor window as possible. I did a tip earlier on how to get into Visual Studio's full screen mode where your entire screen becomes your editor window. However, I understand that full screen mode might not be your cup of tea because getting to the various tool windows -- Solution Explorer, for example -- isn't obvious (you also lose the window's title bar with the standard maximize/minimize/reset buttons).

If you'd like to get the maximum room for your editor's window without giving up the Visual Studio window, then go to the Windows menu and select Auto Hide All. That choice will immediately collapse all of your tool panes -- Solution Explorer, the toolbox, the Properties List and all of their siblings will collapse into the sides of Visual Studio, giving you the maximum editing space inside of Visual Studio. You can, of course, bring back the tool panes you need by clicking on them...but there is no "auto un-hide all" so you have to bring each tool pane back individually.

In Visual Studio 2015, though, you have an alternative to bringing back each tool pane one-by-one: Windows Layouts. To use this, first set up your "preferred" layout of tool panes (probably the one you have in front of you right now). Then assign this Windows layout a name and save it by going to the Window menu and selecting Save Window Layout.

With your preferred layout saved, after using Auto Hide All you can get back to the tool panes you want by selecting Window | Apply Window Layout | <your layout name> from the menu. Saving Windows layouts isn't an option in earlier versions of Visual Studio which only remembered the layouts for four fixed modes: Design, Debug, Full Screen, and File.

Posted by Peter Vogel on 09/01/2016 at 3:07 PM0 comments


Make Sure You're Compressing What You Send to the Browser

This is really a tip for IIS 7 (or later) Web site administrators than it is for developers: Make sure that you've looked at how you're using urlCompression your site. urlCompression ensures that, when the browser supports it, your Web pages and static resources (PDF files, for example) are compressed before being sent to the user. This can reduce the amount of bandwidth used on each user request.

There are three compression options and, since IIS 7.5, the most useful one (dynamic compression, which compresses your Web pages) should be turned on by default. Having said that, I had a client running IIS 10 where even that option was turned off. You probably want to ensure that dynamic compression is turned on and, if your users download a lot of files from your site, that the other choices are turned on also.

However, there are a number of options to manage here and the highest compression settings aren't necessarily the best ones (higher compression settings require more processing time and the savings in bandwidth might not compensate for that processing time). In fact, if you're tight on CPU cycles but have lots of network bandwidth to spare you might actually be better off by not using compression. The best discussion that I've found about the various tradeoffs is here (though the post is rather old).

Posted by Peter Vogel on 08/25/2016 at 12:42 PM0 comments


Upcoming Events

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.