Changing Parameter Values with out and ref

By default, any values that you pass to a method in a parameter are protected from change inside the method. In this code, for example, I know that my variable NotChanged can't be different after I call the method. In this code, the test on the last line is guaranteed to be true:

string NotChanged;
NotChanged = "Fred";
MyOrdinaryMethod(NotChanged);
if (NotChanged == "Fred") ...

That is, unless the parameters to the method are marked with the ref keyword, as in this example:

void MyRefMethod(ref string parm1)
{

Now, if I call this method the value of anything that I pass to that first parameter could be different after calling the method. To make sure that I realize that possibility, the compiler also requires that the calling code use the ref keywords. In this code, the test on the last line is not guaranteed to be true and, thanks to having to provide the ref keyword, I know that:

string PossiblyChanged;
PossiblyChanged = "Fred";
MyRefMethod(ref res);
if (PossiblyChanged == "Fred") ...

While a parameter marked with the ref keyword may or may not be changed, the out keyword is more definite: The out keyword indicates that code inside the method will always change the value in the parameter. If you mark a parameter as out and there is a path through your method that doesn't alter the value of the parameter then the compiler will generate an error.

In addition, with the out parameter, the compiler will refuse to compile your method if, inside your method, you attempt to use the out parameter without first setting its value. In other words, when calling a method with an out parameter, the calling code can set the value of the parameter before passing it to the method -- but it won't do a bit of good because the method has to override that value before it can use the parameter. Again, because I have to use the out parameter when calling the method, I know that:

string DefinitelyChanged;
MyRefMethod(out DefinitelyChanged);
if (DefinitelyChanged == "Fred") ...

That's it for now, I'm out.

Posted by Peter Vogel on 05/05/2016 at 9:37 AM0 comments


Visual Basic 14 Inline Comments

I'm not a big fan of commenting code, which means that when I feel the need to add a comment it's because I feel that the comment is critical to the code's future. As a result, I want any comments I add to have maximum impact/usefulness.

In Visual Basic, however, I can only put comments before or after the statements that I want to comment. This is especially limiting in LINQ queries, which I often break up over multiple lines, putting each LINQ clause on a different line. This means that a comment on the line before the LINQ query may be explaining something three or four lines farther down the screen. 

With Visual Basic 14, I can finally put my comments where I want them: In-line with the part of the LINQ query I want to explain. This example uses a comment to explain a Where clause:

  Dim PremCusts = From c In db.Customers
                  Where c.Id % 2 = 0    'Premium customers have an even numbered id
                  Select c

You can also use in-line comments when you break up a statement over multiple lines using implicit line continuation.

Posted by Peter Vogel on 06/09/2015 at 8:31 AM0 comments


Organize Classes into Folders in Class View

It doesn't show often in the columns I write here, but I'm a big fan of organizing large projects into files. You can, of course, create those folders in Solution Explorer, which adds the folders to your file system.

But, if you use Class View, you know that your Solution Explorer folders don't show up there. As the number of classes in your application starts to increase, the usefulness of Class View starts to diminish. If you want, though, you can also organize Class View into folders … and those folders don't have to match your Solution View folders.

It's not obvious how to do this -- right-clicking in Class View and picking Add from the submenu won't give you a folder option, for example. Instead, you need to click the Add Folder button in the top left-hand corner of Class View. Once you've created your folder, you can drag classes into it (still in Class View, of course). You can also create subfolders (right-clicking on a folder will give you a New Folder option).

These folders only exist in your solution's information file (the .sou file) and aren't added to your file system.

Posted by Peter Vogel on 05/20/2016 at 1:03 PM0 comments


Wrapping Lines in Visual Studio

I was teaching Learning Tree's ASP.NET MVC course a few weeks back. The author of that course decided that having code lines extend past the right-hand edge of the code window wasn't a good idea if you're an instructor demoing some code. To eliminate those disappearing lines on the demo computer we use in the course, he turned on word-wrap for Visual Studio. This choice keeps all of the code on the screen by wrapping long lines of code back to the left hand margin.

If you like that idea, it's easy to turn on that option. Go to Tools | Options | Text Editor | All Languages and select the "Word wrap" choice on the right. That's all you need to do but, if you want, you can also have Visual Studio put a U-turn arrow at the end of each line that's too long to fit in the window -- just click the "Show Visual Glyphs for word wrap" option under the Word wrap choice.

Posted by Peter Vogel on 12/15/2015 at 11:04 AM0 comments


Create .zip Files from Code

If you've ever wanted to create a .zip file from your application, the System.IO.Compression.GZipStream will let you do it, assuming that you're comfortable with your file being in the industry-standard .gzip format (though I'm told you can swap in other compression schemes).

For this tip, I'm assuming that the file is small enough that you can read it all in one gulp. In that scenario, my first move is to define a FileStream object for the file I want to compress, read the file into memory, and close the FileStream:

Dim unCompressedFile As FileStream
unCompressedFile = File.OpenRead("C:\GreatBigFile.txt")
Dim bytes(5000) As Byte
Dim bytesRead As Integer
bytesRead = unCompressedFile.Read(bytes, 0, 5000)
unCompressedFile.Close()

My next move is to create a FileStream object for the compressed file I want to create:

Dim CompressedFile As FileStream
CompressedFile = File.Create("C:\IttyBittyFile.gzip")

With all the files in place, I'm ready to create the GZipStream object that will do the actual compression. You have to pass two parameters when creating the GZipStream object: The first is the FileStream for the compressed file you intend to create; the second indicates that you want to compress the file.

Here's my code to create a compressed file called IttyBittyFile.gzip:

Dim zipper As GZipStream
zipper = New GZipStream(CompressedFile, CompressionMode.Compress)

Now I can use the GZipStream Write method to write out the compressed file, passing the bytes I retrieved from the original file:

zipper.Write(bytes, 0, bytesRead)

Finally, of course, I close the GZipStream object and my compressed file:

zipper.Close()
CompressedFile.Close()

As you probably suspect, if you change the CompressionMode and pass in a compressed file, you can use GZipStream to decompress a file.

Posted by Peter Vogel on 12/10/2015 at 9:46 AM0 comments


What's Important in Coding Conventions

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


The Answer to Every File Path Related Problem

If you do anything at all with file path, you need the Path class (in the System.IO namespace). The methods on the Path class that you're most likely to use include:

  • GetTempFileName: Doesn't just return a filename that's guaranteed to be unique -- it also creates the file in the TEMP folder so you can start writing to it
  • GetFileName: Returns the file name from a path (and returns null if the path is just the path to a folder without a file name)
  • GetDirectoryName: Passed a file path, pulls out the full path to the folder without the closing backslash. One warning: this method returns null if passed the root folder ("c:\")
  • Combine: Puts a set of strings together to create a valid file path. Combine will add or remove backslashes as necessary, so the method will do the right thing with the path return by GetDirectoryName

These are the answers; any more questions?

Posted by Peter Vogel on 08/24/2015 at 2:20 PM0 comments


Multiple Solution Explorers

If you've right-clicked on a project in Solution Explorer, you've probably noticed (but haven't used) the New Solution Explorer View choice. Clicking on that choice with a project selected in Solution Explorer opens a new Solution Explorer view that displays just that project. Initially, the new, dedicated view is free-floating but you can dock it anywhere you want, including docking it as a tab beside your "full" Solution Explorer view.

This is a great alternative to scrolling up and down between two projects in a solution: Once you've opened a view dedicated to a project and docked it, you can just click on the tab that displays the project with which you want to work.

There are two disappointments: You can't name the tab (so you end up with multiple tabs called "Solution Explorer"); Visual Studio doesn't remember your dedicated views from one editing session to another (it also drops any dedicated views if, for example, you add a new project to the solution).

You can actually open a new Solution Explorer view dedicated to almost any item in Solution Explorer, but I've only ever found it useful for projects.

Posted by Peter Vogel on 09/21/2015 at 2:19 PM0 comments


Why Won't My Razor Code Compile!?!

I've said it before: The Razor code that I enter into my ASP.NET MVC Views looks like magic to me. The ability Razor gives me to mix HTML and code surpasses my understanding. But, like magic, because I don't understand why Razor works, there are times where I don't understand why Razor doesn't work.

And neither do my clients, one of whom called me up last week to ask why code like the following wasn't acceptable to Razor (in C#, equivalent code wouldn't require the second @ ... but it still wouldn't compile):

@If RowRequired Then
  @<tr>
End If

The problem is that, inside a code block (like this If…Then block), Razor requires that all open tags have a matching close tag. Razor is fine with this code, for example:

@If RowRequired Then
  @<tr></tr>
End If

This can make structuring your HTML a little more awkward but, there is a solution: use @: instead of plain old @. With @:, this code compiles:

@If RowRequired Then
  @:<tr>
End If
</tr>

That's sharp!

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


Visual Studio in Full-Screen Mode

Even after you maximize Visual Studio's window you don't yet have the maximum space for working with code and the Visual Studio's visual designers. To get the maximum bit of screen real estate available, you can put your Visual Studio edit window in full-screen mode by selecting View | Full screen (or just pressing Shift+Alt+Enter). Full screen mode gets rid of the toolbars and all of your tool windows (Solution Explorer, the Toolbox, etc.); you get to keep the menu bar and the tabs for your open files (though the tabs' appearance is altered to take up less room).

When you need to get out of full-screen mode, all you have to do is click the Full Screen choice that gets added to the menu bar when you enter full screen mode.

You can still display any of the tool windows you want by selecting them from the View menu. You might also want to try memorizing the hot keys that bring up those windows, but those hot key aren't particularly obvious. It helps that the hot keys for the tool windows all begin with Control+Alt. But, unfortunately, Control+Alt+S doesn't bring up Solution Explorer as you might expect. Instead, Control+Alt+S brings up Server Explorer. To get to the Solution Explorer window, you need to use Control+Alt+L (and, no, I have no idea why). Getting to the toolbox is the equally unobvious Control+Alt+X. If there's a shortcut for Test Explorer, I haven't found it yet.

It's not my fault.

But if you're going to bang in a lot of code, it's hard to beat having all that screen real estate. If the hotkeys for the tool windows were more obvious, I'd like it even better.

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


Get the Path to Your File in Visual Studio

One of the best things about Solution Explorer is that I can right-click on a Project, pick "Open Folder in File Explorer" and, a second later, I'm in Windows Explorer, able to work with the files that make up the project. This also works with Solutions or, really, any folder displayed in Solution Explorer (for example, if you have Show All Files turned on, you can use this with the bin folder or obj folders).

Often, however, I'm not focused on the Project (or Solution) as a whole: I'm interested in one specific file -- usually, the one that I have open in my editor window. When that's the case, I can just right-click on the file's editor tab and select "Open Containing Folder." This not only opens the appropriate folder in Windows Explorer, it also selects and highlights the file I'm interested in.

Posted by Peter Vogel on 04/21/2016 at 12:22 PM0 comments


Integrating Ajax and Partial Views in ASP.NET MVC

In previous columns, I've discussed options in assembling your View from a set of partial Views. However, in all of those examples, I've been assembling a View on the server in response to a request from the client.

The cool thing is that you can also return partial Views to Ajax calls. Here's a getJson call to a ASP.MVC Controller's Action method that expects to get back a set of HTML that it inserts into a page's div element:

$.ajax({
        data: InfoAndData,
        datatype: "text/plain",
        type: "POST",
        url: 'MyController/MyAction',
        cache: false,
        success: function (data) {
                $('#divDisplay').html(data);
            }
        });

The Action method, accepts the data from the Ajax call in the same way as it does any other request but uses the PartialView method to trigger processing of the partial View and have the resulting HTML sent to the client:

Public Function MyAction(InfoAndData As InfoClass) As ActionResult
   ... code to retrieve data based on values in InfoAndData ...
   ... load results ... 
  Return PartialView("MyView", results)
End Function

There are lots of things to like about this approach -- having your HTML generated in a View is consistent with the way that the rest of your HTML is created. You also have access to all of Razor's tools for creating HTML (including localization). Finally, of course, your client-side code is reduced because you don't have to write the code to insert each data item into the page.

But there are at least two things to dislike: The payload being returned (HTML + data) is almost certainly going to be larger than the equivalent JSON object holding just the relevant data. The cycles required to generate the HTML may or may not be equivalent to cycles required to insert the data/set up the HTML on the client.

However, the server-side cycles are on a shared resource while the client-side cycles are on the user's computer. Using server-side cycles makes your application less scalable (personally, I feel that the user's computer should be regarded as free, unlimited resource that should be exploited mercilessly).

For me, I like using partial Views enough (and regard the costs of sending partial views as sufficiently low) that I frequently use this technique.

Posted by Peter Vogel on 06/30/2015 at 10:32 AM0 comments


.NET Insight

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.

Upcoming Events