Awesome ClientSide Syntax Highlighter.

For the two people subscribing to this blog, my apologies for the 8 million test posts.

Via Jeff Atwood I stumbled upon this fantastic client side syntax highlighter for web pages/blogs. Here's a sample below:

/*********************************** ** My Class **********************************/ public class MyClass {    private string _name = string.Empty;    public MyClass(){ /* constructor */}    public void DoSomething    {     if(true)     { // print the name     Console.WriteLine(_name);     } }

I post a fair amount of code snippets so felt it was worth the effort to get this installed. It took a few trys though. First I needed to take the multiple files supplied and incorporate them directly into my Blogger template. Then via a ton of trial and error, I finally figured out that a) having any html tags (such as a <br>) within the textarea tag "shuts off" the formatting, and that b) by default both my blog editor (w.bloggar) and Blogger converted newlines into br tags. This latter feature is great when I'm being lazy about the html in my post, but it was killing my code samples. So I've turned off that feature, but now my previous posts look like crap since I was being lazy. Oh, well it'll give me something to do this weekend, cleaning those all up - but at least now my code samples will look really, really cool!

Test Code Highlighter 4

Testing a syntax highlighter 4 ...
// single line comments // second single line override protected void OnLoad(EventArgs e) { if(Attributes["class"] != null) { //_year.CssClass = _month.CssClass = _day.CssClass = Attributes["class"]; } // base.OnLoad(e); } /*********************************** ** Multiline block comments **********************************/

AppDomain.CurrentDomain.UnhandledException is *not* an exception handler (it's just an event)

To some the title of this post may be a no-brainer. But, until this afternoon I thought that AppDomain.CurrentDomain.UnhandledException was some sort of "global" exception handler (iow, a giant try ... catch around everything). Hook up a method, log the exception and you the coder decide whether to let the app continue on it's merry way. And never, ever see that standard .NET crash dialog (after all if I've "handled" the exception why is CLR stepping in?). Only it wasn't working that way at all. No matter what I did I was still seeing the crash dialog. (And some other weird behavior I can only attribute to the fact this was a Windows Service). I googled and googled and couldn't find anything. Then finally I found I wasn't alone. Thankfully, the final comment on that post by Jonathan Keljo (CLR Exception PM), kicked the lightbulb on. In part Jonathan explained:

The first thing to understand is that the UnhandledException event is not an unhandled exception "handler". Registering for the event, contrary to what the documentation says :-(, does not cause unhandled exceptions to be handled. (Since then they wouldn't be unhandled, but I'll stop with the circular reasoning already...) The UnhandledException event simply notifies you that an exception has gone unhandled, in case you want to try to save state before your thread or application dies.

So it's just an event handler, giving you one last chance to clean up or log, or whatever before the CLR handler kicks in. (Be sure to read the rest of his comments and this article to understand how unhandled exceptions are "handled" by the CLR for various thread types. In some cases your app won't die at all in v1.0 and v1.1.) Oh, and btw, if anyone has links to some decent articles on "hardening" a Windows Service please comment. At this point all I can come up with is a try catch in the .ctor, and the OnStart, OnStop, etc. methods. But, other than logging can't figure out what I should be doing in the catch block.

Restraining your inner Colonel Jessup (You can't handle the truth!)

This was brilliant. To be honest, there are days when I too wish I could just mandate some things and get the talking over with.

Peel away the Abstractions - Reference Types, Value Types, ByRef, ByVal, where are my pointers?

Aaron pointed out this pretty decent article by Jon Skeet that describes the difference between value and reference types in .NET. In that article Jon points to another article of his that describes the difference of passing by value and passing by reference in .NET. I read both articles with interest because this question comes up at times at work, and I'm always grasping for a simple way to explain it. As hard as I try, I still find the easiest way to understand these things is to reach back to C and understand pointers. That's what's really going on under the .NET covers. MyCSharpMethod(ref Object o) is equivalent to MyCMethod(Object** o), it's as simple as that once you understand pointers.

Other Languages: The return keyword - use it!!

In VB "classic" there is no return keyword, rather you assign the return value to the function name. So, that would look like something like this: Public Sub SomeProcedure Dim result As Integer result = AddFunction(1,1) MsgBox(result) End Sub Public Function AddFunction(paramOne As Integer, paramTwo As Integer) AddFunction = paramOne + paramTwo End Function Way back when I was first (re) learning programming the VB "classic" syntax for returning values from a method/function made perfect sense to me. Back then, to a hobbyist with no concept of stack frames and such, a function call looked an awful lot like a variable, so why not just assign to it? It's funny how quickly confusing syntax like this becomes a distant memory. I'd completely forgotten that VB.NET, while providing a Return keyword, still supports the above syntax. Until yesterday. A coworker asked me to help him figure out a bug. We stepped into a property accessor only to be completely confused when we saw the code assigning to the property, and then using the Exit Property keyword to break out of the accessor. It took minutes for it to dawn on me that the assignment wasn't calling the property setter, and that Exit Property was legal syntax. I'd just like to say, please don't use this syntax! It is confusing and misleading. In a property it looks downright wrong! (Can you say stack overflow!!) In the interest of readable code use the return keyword. (I poked around to see if there was any other language that didn't use return. All of the C derivatives - C, C++, C# and Java use it. Python uses it. Interestingly, Ruby has the return keyword, but it isn't always required. If you don't explicitly return a value, Ruby returns the value of the last executed statement in the method. I still stand by my assertion that such "implicit" help from the interpreter/compiler makes code less readable.)

No, really, who am I? (The video game character thing)

I am a Defender-ship. I am fiercely protective of my friends and loved ones, and unforgiving of any who would hurt them. Speed and foresight are my strengths, at the cost of a little clumsiness. I'm most comfortable with a few friends, but sometimes particularly enjoy spending time in larger groups. What Video Game Character Are You?

Interestingly, the "fiercely protective ..." part is really true, as is the "I'm most comfortable with a few friends". The speedy, foresight, clumsy thing, not so sure about ...

Sniffing out stinky code

Good naming conventions and practice can really help make code more readable, and even help prevent hard to find bugs. Mike Clark gives a concise, yet thorough explanation of how well written code can be self-documenting, as well as when, why and how to comment your code in the article Write Sweet-Smelling Comments. I particularly got a laugh out of his examples of good comments in the box "eye-popping comments". I had started feeling guilty about the "police tape" style comments I'd liberally sprinkled throughout a particular code base. Seeing Mike's example was extremely validating, and I now proudly stand by those comments. In a completely different vein, but still on the topic of code clarity, Joel Spolsky makes a convincing argument for "Apps" Hungarian notation as a valuable tool for "Making Wrong Code Look Wrong", thus preventing hard to find bugs. I'll admit that early on in my programming career I succumbed to the "wrong" way of doing Hungarian, but even today in my not a bit of Hungarian anywhere .NET code, I rely heavily on certain conventions to make my code readable. For instance I'm a huge fan of "_" as a prefix for member variables, which makes them easy to recognize when reading code. Casing and other conventions are additional tools that I love to take advantage of. (This is a big reason I prefer case-sensitive languages. I like to be able to enforce that someVariable and SomeVariable are two different things, and hence be able to attach meaning to the different cases)

To GAC or not to GAC

This question comes up at work from time to time, mostly in a rhetorical sense. The GAC represents a great way to share and version assemblies across multiple applications. If you remember "DLL Hell", then you can understand, if not feel, the shudder that paralyzes me when I hear of that kind of functionality. Chris Sells summarized my feelings on the subject very well in his post Avoid the GAC. On the other hand, Junfeng points out that 'Avoid the GAC' is not official MS policy, and that the GAC should be used 'whenever it makes sense' for 'shared components'. I agree, that like most decisions, you can't make a blanket statement to never use the GAC. However, personally this is one of those things where I would err on the side of just don't use it. If you think we do need it, you had better be prepared to convince me why- (hint: simply saying more than one app is going to use the assembly isn't going to cut it.)