He uses a tool from Microsoft called XNA for making DirectX-based games.

For basic effects on lighting, textures, etc., you have to make a change, recompile, and see if it was what you wanted. Major pain.

He made an external tool that lets folks import in the object and then adjust all of the BasicEffect settings in real-time.

When the user gets it how they want, they can save all of the properties and throw it back into XDA.

A pet-peeve of mine is when I work on code that written with legacy VB6-style methods and functions rather than the more current .NET versions.

Is there a huge performance penalty between calling Len() on a string versus .Length and that sort of thing? Not really. I mean, I’m sure there probably is on some level, but nothing a user is likely to notice in an average application.

My big gripe is that by forcing yourself to use what’s in the framework only, you can sometimes find better ways of doing things.

The best example for that I can give is the use of IsNumeric(). In applications I’ve worked on, I’ve often seen code where the validation of a textbox (for the input of an order number, for instance) uses IsNumeric to check to see if the number is valid and then will blindly set the value of a variable, parameter, etc. to it that is an Integer, a Long, or whatever.

For this example, let’s assume that the order number field is an Integer.

Here are a few inputs that pass the IsNumeric() test:

The first three are mathematically valid, so let’s ignore those for now. I rather not accept leading + or – characters unless we are working with values that can legitimately be negative or positive.

The last three items on the list are a bit more interesting, though.

In strict terms, “$5″ isn’t a valid number. If we explicitly cast it to an integer with CInt(), it’s smart enough to trim off the dollar-sign, but is that what you want? Call me old-fashioned, but I like predictability… If I have a field that only is meant for numbers, it shouldn’t work if I throw in something that isn’t a number.

With “5.5″, it’s clearly not an integer. If the code simply checks the input against IsNumeric() and then runs CInt(), it will round the value up to 6. Assuming it was a legitimate typo, if the user attempted to search for order 55 and got back order 6, it might lead to confusion. It’s better to err on the side of caution up front, having them fix the input before searching again.

Lastly, there’s a search for “2147483648″, which is one digit higher than the maximum size an integer data-type can be. It will pass the IsNumeric() test, but will cause an overflow when CInt() is attempted. Not good. Unless you have pretty robust exception-handling (and I don’t mean just tossing everything into a Try/Catch block), this can either result in unexpected behaviors within the app or, more often, user-facing errors that aren’t easy for them to understand.

The alternative solution to the above scenario is to use Integer.TryParse() With that method, you’re not only evaluating the string value to see whether it can be converted to an integer, but (assuming it can be converted and you passed in a variable as the second parameter instead of Nothing) it also does the conversion for you. With the above list of inputs, the only ones that pass the Integer.TryParse() method are the first three. And, again, if I wanted to be even more picky, I could reject the + or – prefixed input for maximum consistency.

Regular-expressions might be good for an initial validation pass, I guess, but that’s a whole other topic…

Ok, great, but so what…?

What does this all have to do with C#? Very little… I just wanted to explain my motivations for wanting to prevent some of this stuff from finding its way into new code and to identify legacy implementations that probably need cleaned up. It’s not just IsNumeric() that I have an issue with, it’s also IsDate(), which can be easily handled through Date.TryParse, UCase, Len, Space, Left, Right, Mid, InStr, MsgBox, Format, Replace, LikeString, etc., etc., etc.

I needed to identify where in the code these were being called, but it should be done in such a way as to allow me to make exceptions when needed and to differentiate between the Good, Bad, and the Ugly of VB calls…

For that, I needed FxCop…

That is where the C# stuff came in.

Aside from there not seeming to be any (at least not useful) official documentation on FxCop, I had to rely on third-party examples. Once I got over the initial issues of using the newest version of FxCop with samples code made for old versions of it, I eventually got the gist of what was being done.

To make a custom FxCop rule required me to make a C# library DLL with the various introspection rules. It also needed an XML file saved as an embedded resource, which wasn’t too involved.

Really, the hardest part of writing the custom rules was figuring out how the introspection was evaluating the code and, more importantly, what I needed to change in order for it to evaluate what I wanted.

My goal was simple enough. For starters, just show everything that referenced the Microsoft.VisualBasic namespace. Once I got that working, I’d figure out how to narrow it down just to the stuff that I wanted to no longer use in new code.

I’m still tweaking it a bit, but I finally got it working (mostly) the way I want. I go within the MethodCall and examine the Method’s DeclaringType.FullName… If it starts with “Microsoft.VisualBasic”, I know I’m on the right track… There are a couple namespaces that I exclude right off the bat (like “Microsoft.VisualBasic.CompilerServices.Conversions” and “Microsoft.VisualBasic.CompilerServices.ProjectData”). Otherwise, I call a custom routine of mine that categorizes the call into a few different rule categorizes I came up with.

To categorize the call, I use a combination of the method’s namespace as well as GetUnmangledNameWithoutTypeParameters(true)

Everything In Its Place

I came up with four categorizes:

This seemed to do the trick. I could now analyze any project I was working with an see how many calls were using “the old way”

Ultimately, it came down being more of a conversation starter than anything else.

Some calls, like with those to MsgBox, were brought over from older code, while all of the new code was written using the .NET Framework alternatives. Other times, there were calls even in the new code being made because no one had realized there were other (better?) ways of doing the same thing.

For more, the call I used a lot, but hadn’t realized there was an alternative to was IsNothing() I’ve slowly been trying to break my habit, if for no other reason than it’s so much easier to read “If SomeValue Is Not Nothing” rather than “If Not IsNothing(SomeValue)”. It’s a subtle difference when writing it, but more of a value when it’s being read (especially by someone else).

Ultimately…

I enjoyed learning and working with C# a bit. I still think case-sensitivity is retarded, but there’s a lot about C# that I started to get used to really quickly.

I don’t know, I’ll probably do a few more small projects with it and see how it goes.

You are given the following information, but you may prefer to do some research for yourself.

* 1 Jan 1900 was a Monday.
* Thirty days has September,
April, June and November.
All the rest have thirty-one,
Saving February alone,
Which has twenty-eight, rain or shine.
And on leap years, twenty-nine.
* A leap year occurs on any year evenly divisible by 4, but not on a century unless it is divisible by 400.

How many Sundays fell on the first of the month during the twentieth century (1 Jan 1901 to 31 Dec 2000)?

Solution:
Function Prob019() As Long
Dim dt As Date = CDate("01/01/1901")
While dt < = CDate("12/31/2000")
If dt.DayOfWeek = System.DayOfWeek.Sunday Then Prob019 += 1
dt = dt.AddMonths(1)
End While
End Function

Summary:
I'm not above cheating by using built-in functions

The following iterative sequence is defined for the set of positive integers:

n → n/2 (n is even)
n → 3n + 1 (n is odd)

Using the rule above and starting with 13, we generate the following sequence:
13 → 40 → 20 → 10 → 5 → 16 → 8 → 4 → 2 → 1

It can be seen that this sequence (starting at 13 and finishing at 1) contains 10 terms. Although it has not been proved yet (Collatz Problem), it is thought that all starting numbers finish at 1.

Which starting number, under one million, produces the longest chain?

NOTE: Once the chain starts the terms are allowed to go above one million.

Solution:
Function Prob014() As Long
Prob014 = 0
Dim NumWithLargestChain As Long = 0
Dim ChainCount As Long = 0
For StartNumber As Long = 999999 To 1 Step -1
Dim tmpNum As Long = StartNumber
Dim tmpCount As Long = 0
Do
tmpCount += 1
If tmpCount > ChainCount Then
ChainCount = tmpCount
NumWithLargestChain = StartNumber
End If
If tmpNum = 1 Then Exit Do
If tmpNum Mod 2 = 0 Then
tmpNum = tmpNum / 2
Else
tmpNum = (tmpNum * 3) + 1
End If
Loop
Next
Return NumWithLargestChain
End Function

Summary:
Thankfully, this was a lot easier than the previous problem I did. I skipped problem 12 and 13, but I’ll probably come back to them at some point. Problem 12 dealt with triangle numbers, which I’m not really familiar with. Problem 13 dealt with adding up a hundred 50-digit numbers, which seems like it would be easy, but I either would need a crazy-big numeric datatype or I’d need to come up with a new way to add the stuff up through some other fashion.

In the 20×20 grid below, four numbers along a diagonal line have been marked in red.

08 02 22 97 38 15 00 40 00 75 04 05 07 78 52 12 50 77 91 08
49 49 99 40 17 81 18 57 60 87 17 40 98 43 69 48 04 56 62 00
81 49 31 73 55 79 14 29 93 71 40 67 53 88 30 03 49 13 36 65
52 70 95 23 04 60 11 42 69 24 68 56 01 32 56 71 37 02 36 91
22 31 16 71 51 67 63 89 41 92 36 54 22 40 40 28 66 33 13 80
24 47 32 60 99 03 45 02 44 75 33 53 78 36 84 20 35 17 12 50
32 98 81 28 64 23 67 10 26 38 40 67 59 54 70 66 18 38 64 70
67 26 20 68 02 62 12 20 95 63 94 39 63 08 40 91 66 49 94 21
24 55 58 05 66 73 99 26 97 17 78 78 96 83 14 88 34 89 63 72
21 36 23 09 75 00 76 44 20 45 35 14 00 61 33 97 34 31 33 95
78 17 53 28 22 75 31 67 15 94 03 80 04 62 16 14 09 53 56 92
16 39 05 42 96 35 31 47 55 58 88 24 00 17 54 24 36 29 85 57
86 56 00 48 35 71 89 07 05 44 44 37 44 60 21 58 51 54 17 58
19 80 81 68 05 94 47 69 28 73 92 13 86 52 17 77 04 89 55 40
04 52 08 83 97 35 99 16 07 97 57 32 16 26 26 79 33 27 98 66
88 36 68 87 57 62 20 72 03 46 33 67 46 55 12 32 63 93 53 69
04 42 16 73 38 25 39 11 24 94 72 18 08 46 29 32 40 62 76 36
20 69 36 41 72 30 23 88 34 62 99 69 82 67 59 85 74 04 36 16
20 73 35 29 78 31 90 01 74 31 49 71 48 86 81 16 23 57 05 54
01 70 54 71 83 51 54 69 16 92 33 48 61 43 52 01 89 19 67 48

The product of these numbers is 26 × 63 × 78 × 14 = 1788696.

What is the greatest product of four adjacent numbers in any direction (up, down, left, right, or diagonally) in the 20×20 grid?

Solution:
Function Prob011() As Long
Prob011 = 0
Dim strGrid = ""
strGrid &= " 08 02 22 97 38 15 00 40 00 75 04 05 07 78 52 12 50 77 91 08"
strGrid &= " 49 49 99 40 17 81 18 57 60 87 17 40 98 43 69 48 04 56 62 00"
strGrid &= " 81 49 31 73 55 79 14 29 93 71 40 67 53 88 30 03 49 13 36 65"
strGrid &= " 52 70 95 23 04 60 11 42 69 24 68 56 01 32 56 71 37 02 36 91"
strGrid &= " 22 31 16 71 51 67 63 89 41 92 36 54 22 40 40 28 66 33 13 80"
strGrid &= " 24 47 32 60 99 03 45 02 44 75 33 53 78 36 84 20 35 17 12 50"
strGrid &= " 32 98 81 28 64 23 67 10 26 38 40 67 59 54 70 66 18 38 64 70"
strGrid &= " 67 26 20 68 02 62 12 20 95 63 94 39 63 08 40 91 66 49 94 21"
strGrid &= " 24 55 58 05 66 73 99 26 97 17 78 78 96 83 14 88 34 89 63 72"
strGrid &= " 21 36 23 09 75 00 76 44 20 45 35 14 00 61 33 97 34 31 33 95"
strGrid &= " 78 17 53 28 22 75 31 67 15 94 03 80 04 62 16 14 09 53 56 92"
strGrid &= " 16 39 05 42 96 35 31 47 55 58 88 24 00 17 54 24 36 29 85 57"
strGrid &= " 86 56 00 48 35 71 89 07 05 44 44 37 44 60 21 58 51 54 17 58"
strGrid &= " 19 80 81 68 05 94 47 69 28 73 92 13 86 52 17 77 04 89 55 40"
strGrid &= " 04 52 08 83 97 35 99 16 07 97 57 32 16 26 26 79 33 27 98 66"
strGrid &= " 88 36 68 87 57 62 20 72 03 46 33 67 46 55 12 32 63 93 53 69"
strGrid &= " 04 42 16 73 38 25 39 11 24 94 72 18 08 46 29 32 40 62 76 36"
strGrid &= " 20 69 36 41 72 30 23 88 34 62 99 69 82 67 59 85 74 04 36 16"
strGrid &= " 20 73 35 29 78 31 90 01 74 31 49 71 48 86 81 16 23 57 05 54"
strGrid &= " 01 70 54 71 83 51 54 69 16 92 33 48 61 43 52 01 89 19 67 48"

'Diag-Right
For f As Integer = 0 To 16
Dim Val1 As Integer = 0
Dim Val2 As Integer = 0
Dim Val3 As Integer = 0
Dim Val4 As Integer = 0
Dim StartPos As Integer = (Offset * 3) + (f * CharPerLine)
Dim GroupCount As Integer = 1
While GroupCount < = 17
Val1 = CInt(strGrid.Substring(StartPos, Offset).Trim)
Val2 = CInt(strGrid.Substring(StartPos + CharPerLine - Offset, Offset).Trim)
Val3 = CInt(strGrid.Substring(StartPos + (CharPerLine * 2) - (Offset * 2), Offset).Trim)
Val4 = CInt(strGrid.Substring(StartPos + (CharPerLine * 3) - (Offset * 3), Offset).Trim)
If Val1 * Val2 * Val3 * Val4 > Prob011 Then Prob011 = Val1 * Val2 * Val3 * Val4
StartPos += Offset
GroupCount += 1
End While
Next
End Function

Summary:
I had a LOT of fun figuring out a solution to this one! I was pretty sure there was a way to use a Matrix for this, but — mainly because I can’t remember the last time I’ve actually used one — I skipped the matrix and went with a slightly less elegant way.

The sum of the primes below 10 is 2 + 3 + 5 + 7 = 17.

Find the sum of all the primes below two million.

Solution:
Function Prob010() As Long
For k As Integer = 2 To 2000000
If IsPrime(k) Then Prob010 += k
Next
End Function

Summary:
They are making this WAY too easy. I’m not sure if it’s just the nature of this sort of problem or whether my IsPrime routine needs some tweaking, but this problem takes the longest compared to all of the others I’ve done up to this point. Even so, it’s only 10-seconds, which is well within the target range allowed by Project Euler.

A Pythagorean triplet is a set of three natural numbers, a < b < c, for which,
a^(2) + b^(2) = c^(2)

For example, 3^(2) + 4^(2) = 9 + 16 = 25 = 5^(2).

There exists exactly one Pythagorean triplet for which a + b + c = 1000.
Find the product abc.

Solution:
Function Prob009() As Long
For a As Integer = 0 To 1000
For b As Integer = 0 To 1000
For c As Integer = 0 To 1000
If (a + b + c) = 1000 AndAlso a < b AndAlso b < c AndAlso System.Math.Pow(a, 2) + System.Math.Pow(b, 2) = System.Math.Pow(c, 2) Then Return a * b * c
Next
Next
Next
End Function

Summary:
Pretty easy...

Find the greatest product of five consecutive digits in the 1000-digit number.

73167176531330624919225119674426574742355349194934
96983520312774506326239578318016984801869478851843
85861560789112949495459501737958331952853208805511
12540698747158523863050715693290963295227443043557
66896648950445244523161731856403098711121722383113
62229893423380308135336276614282806444486645238749
30358907296290491560440772390713810515859307960866
70172427121883998797908792274921901699720888093776
65727333001053367881220235421809751254540594752243
52584907711670556013604839586446706324415722155397
53697817977846174064955149290862569321978468622482
83972241375657056057490261407972968652414535100474
82166370484403199890008895243450658541227588666881
16427171479924442928230863465674813919123162824586
17866458359124566529476545682848912883142607690042
24219022671055626321111109370544217506941658960408
07198403850962455444362981230987879927244284909188
84580156166097919133875499200524063689912560717606
05886116467109405077541002256983155200055935729725
71636269561882670428252483600823257530420752963450

Solution:
Function Prob008() As Long
Dim strInput As New System.Text.StringBuilder
strInput.Append("73167176531330624919225119674426574742355349194934")
strInput.Append("96983520312774506326239578318016984801869478851843")
strInput.Append("85861560789112949495459501737958331952853208805511")
strInput.Append("12540698747158523863050715693290963295227443043557")
strInput.Append("66896648950445244523161731856403098711121722383113")
strInput.Append("62229893423380308135336276614282806444486645238749")
strInput.Append("30358907296290491560440772390713810515859307960866")
strInput.Append("70172427121883998797908792274921901699720888093776")
strInput.Append("65727333001053367881220235421809751254540594752243")
strInput.Append("52584907711670556013604839586446706324415722155397")
strInput.Append("53697817977846174064955149290862569321978468622482")
strInput.Append("83972241375657056057490261407972968652414535100474")
strInput.Append("82166370484403199890008895243450658541227588666881")
strInput.Append("16427171479924442928230863465674813919123162824586")
strInput.Append("17866458359124566529476545682848912883142607690042")
strInput.Append("24219022671055626321111109370544217506941658960408")
strInput.Append("07198403850962455444362981230987879927244284909188")
strInput.Append("84580156166097919133875499200524063689912560717606")
strInput.Append("05886116467109405077541002256983155200055935729725")
strInput.Append("71636269561882670428252483600823257530420752963450")
Dim Group1 As Integer = 0
Dim Group2 As Integer = 0
Dim Group3 As Integer = 0
Dim Group4 As Integer = 0
Dim Group5 As Integer = 0
Dim StringPos As Integer = 0
Do While StringPos < strInput.Length - 4
Group1 = strInput.ToString.Substring(StringPos, 1)
Group2 = strInput.ToString.Substring(StringPos + 1, 1)
Group3 = strInput.ToString.Substring(StringPos + 2, 1)
Group4 = strInput.ToString.Substring(StringPos + 3, 1)
Group5 = strInput.ToString.Substring(StringPos + 4, 1)
If Group1 * Group2 * Group3 * Group4 * Group5 > Prob008 Then Prob008 = Group1 * Group2 * Group3 * Group4 * Group5
StringPos += 1
Loop
End Function

Summary:
It isn’t pretty, but it works

By listing the first six prime numbers: 2, 3, 5, 7, 11, and 13, we can see that the 6^(th) prime is 13.

What is the 10001^(st) prime number?

Solution:
Function Prob007() As Long
Dim k As Integer = 1
Dim PrimeCount As Integer = 0
Dim TargetPrime As Integer = 10001
While PrimeCount < = TargetPrime
k += 1
If IsPrime(k) Then PrimeCount += 1
If PrimeCount = TargetPrime Then Return k
End While
End Function