In the post, Multiple Parameters of the Same Type in C#: Problems and Potential Solutions, I created a Size struct whose constructor takes a Width object and a Height object as input. The constructors for these objects each take an int value to represent the number of pixels (actually logical pixels) in each dimension. That works if you always want to use pixels as your dimensions. But what happens if you also want to use dimensions of inches, centimetres, or screen width and height percentages?
This post will look at three potential solutions and give the pros and cons of each. A comparison to C++ solutions will also be given. Read more ›
Back in January, I wrote a post called Strong Typing or Naked Primitives in which I discussed possible solutions to using naked primitives (built-in data types) as arguments to functions in C++. This post will look at the same problem and possible solutions for using built-in data types as parameter types in functions in C# code.
What is a built-in data type? A built-in data type is baked into the language; int, float, double, bool, and string are examples of built-in data types.
There are no problems with using built-in data types, and indeed, user-defined data types, as parameters in function calls as long as each parameter is of a different type and there is no implicit conversion among the types. But problems can arise if this is not the case. This post will first show an example of the kind of problem that can occur when two or more parameters are of the same type, and then investigate a number of different solutions to the problem. Read more ›
In the previous post, I discussed unit testing of my Visual Studio extension for generating documentation comments. This post continues the discussion about testing by looking at integration, system, and acceptance testing.
While I will eventually be writing a large amount of code for this project, the project itself is very contained in where it integrates into Visual Studio. That is, there will be one menu item that executes the code. In my post, Testing, 1, 2, 3, I provided the following definitions:
- Integration tests validate the interfaces and interactions between components. These are black or gray box tests.
- System tests validate that the integrated system meets specified requirements. These are black box tests.
The integration tests definition mentions interfaces. Does that mean UI interfaces? Do I need to be selecting the menu item for each integration test? Read more ›
I have discussed testing in several posts and also the creation of a documentation comments generator over the last 5 posts. This post and the next one will bring the two topics together. That is, I will be discussing how to test the generator.
In the post, Testing, 1, 2, 3, I gave the four levels of testing as unit testing, integration testing, system testing, and acceptance testing. I will discuss what testing I do for each of these. This post is limited to discussing unit testing. Read more ›
There are two tools which I have found to be invaluable as I develop my documentation comments generator. These tools are the Syntax Visualizer, and RoslynQuoter.
Syntax Visualizer is a Visual Studio extension that is installed as part of .Net Compiler Platform SDK. To view the Syntax Visualizer, click on View->Other Windows->Syntax Visualizer in Visual Studio. The syntax visualizer window opens and displays the syntax for the code in the active editor window. Here is what the syntax visualizer looks like: Read more ›
In the last post, Creating A Documentation Comment Generator For C#: Setting Up The Framework, I discussed a framework for analyzing the source code and generating documentation comments. I mentioned that three steps are involved:
- Retrieve the source code for the active document.
- Modify the source code to contain the documentation comments.
- Replace the source code in the active document with the modified source code.
I showed all of the code necessary for steps 1 and 3. The code for step 2 was also shown and is repeated here:
var syntaxTree = CSharpSyntaxTree.ParseText(code);
var root = syntaxTree.GetRoot();
var rewriter = new DocumentCommentsRewriter();
var newCode = rewriter.Visit(root).ToFullString();
code contains the source code that was retrieved from the active document, and newCode is the source code modified to contain the documentation comments; it is the code that is written back to the active document. That’s all there is to it! The source code analysis and generation of the documentation comments occurs in the DocumentCommentsRewriter class. This post will look at the contents of that class.
Read more ›