The FogBugz Plugin Architecture

Oh, that's too bad. I'm thinking about writing a plugin for FogBugz, and that would have been nice to have (it won't stop me from writing it though ;)

Perhaps they could check out LINQbridge (http://code.google.com/p/linqbridge/). I don't know if that could be adapted to work for them and ease the transition to .NET 3.5, but perhaps its something to look at. (It almost replicates LINQ on the 2.0 framework.)

> ugh, global functions, I know

> FogCreek.FogBugz.Url class just has some static methods to generate URLs

Honest question, why does one gross you out and not the other? I don't do .NET and in the Python community "global functions" aren't looked down on, so I'm just trying to learn something.

Reasonably strong typing + better IDEs have made type-naming redundant. If you don't have both those two available, go ahead and use it though.

It depends on language.

In Delphi/Object Pascal the convention is/was to prefix classes with T or TProjectName. Because Pascal is case-insensitive language, classes are prefixed to avoid mixing them with variables (Cat = TCat.Create).

In Objective C classes are usually prefixed with two capital letters (unique for company or project), like NSString. Because ObjC/C doesn't have namespaces, this serves the purpose of avoiding collisions with other classes that may have the same name. So yes, while it's a convention, it's here because there's no latest advances in technology to make it obsolete.

In Ruby you don't have to prefix classes because there's a convention, enforced by language, to write class names in title case.

In C#, the convention is not to prefix classes with letters, since it's case sensitive, has namespaces, and compiler takes care of type checking.

Once upon a time a Hungarian chap named Simonyi invented a system of prefixing variables with letters to describe their type. This was actually a very good idea since at the time computer programs were rapidly growing in size and complexity, and developers did not have any of the fancy IDE features nor large high-resolution screens that we take for granted today.

However as with many good ideas it was became taken to excess and and variables eventually became less readable - e.g. m_spszName would be a member variable, that is static, and is a pointer to a zero-terminated string. It did not help that people often disagreed the order of prefixes, or only used a subset of the full range.

With the advent of better type-checking compilers and languages, intellisense IDE features, and screens that could display more than 80 lines Hungarian notation largely faded away.

The 'C' prefix was originated (I think by MFC) to signify that a type was a class. Ironically it began around the time that strict Hungarian notation began to fade out, and classes became liberally used in code.

There are still many good reasons to use certain prefix's on your variable ('m' for member being the most widely used) but things like CFoo or pszName are largely antiquated relics of a past time.

It just gave me a little chuckle when I saw it :)

Hungarian notation was (if I recall correctly) invented for use in BCPL which was a language which had only one type, the 16 bit integer, which was used for both pointers and any other type of data. It is pretty important to avoid e.g. treating a boolean as a pointer, but since the language itself didn't offer any way to distinguish between these types, it was proposed to encode type info in the variable names. So pointer variables was prefixed with ptr, booleans with b and so on. That way the developers could perform manual type-safety checks when they read and wrote code.

Modern type systems have of course made that obsolete.

Ignore the Hungarian haters.

Joel's stance on Hungarian notation is laid out here: http://www.joelonsoftware.com/articles/Wrong.html