Instead of having your plugins be able to execute SQL commands, why not use something like ActiveRecord + NHibernate (or some other ORM) with LINQ? NHibernate 2.1 was just released with LINQ support, so you could do something like:
int BugCount = Bug.Where(case => case.Id = caseId).Count();
(Where caseId is a parameter or something). It'd really simplify the API and keep you from doing safety checks on the SQL passed by the plugins. You might even be able to simply some of your "display" code to use Dynamic LINQ queries for the sorting and so forth.
I've been using the ASP.NET MVC + NHibernate + ActiveRecord + LINQ "stack" for several months now (though I've been an ASP.NET developer for about five years), and I have to say that my productivity has gone way up thanks to it.
FogBugz targets .NET 2, which lacks .NET Expressions; they'd have had to build their own AST model, without C# support. I wouldn't be surprised if, whenever FogBugz gets around to requiring .NET 3.5, they start supporting LINQ queries against the exposed datasets, but I wouldn't hold your breath.
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.)
I agree this is one of the sillier Hungarian notation conventions, but with that said it does help with a couple things. First, I can look at the file CBug.was and know it contains a class, vs util.was which contains global utility functions (ugh, global functions, I know). Second, in .NET we've adopted the convention that "C" classes are meant to be instantiated, and non-"C" classes aren't. So the FogCreek.FogBugz.Url class just has some static methods to generate URLs, whereas FogCreek.FogBugz.CBug is actually an object that you instantiate and do stuff with.
I'd never use it on a new project, but it's not 100% worthless...
> 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.
Wasabi--which is what FogBugz is (mostly) written in--has honest-to-goodness global functions, which are very different beasts from Python's module-scoped functions (unless you import * from one). I might be wrong, but I suspect that's what bothers df07.
Please explain for the dummies: is this sort of naming convention just a fad that is out of style or has some of the latest advances in technology made it obsolete?
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.
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.
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.
He assumes that you cannot create you own types, e.g just create a HtmlEncodedString class. This was relevant in C and VBScript, but certainly not in C# or any other modern language I know of. Hungarian notation is a manually checked safeguard against wrong conversions when the language is not powerful to check it automatically. It is just cargo cult programming to keep using it in modern languages.
Note that his examples are in VBScript (a language which is as obsolete as BCPL). This might also explain his aversion towards exceptions.
Joel is a great writer and have many great points (also in this article), but understand that his coding advice is from a different era.
Which would be basically everyone who didn't learn to write software on Windows.
If you have a reasonable type system and language, leverage it to enforce semantics that Spolsky suggests you use Hungarian notation to imply by convention.
You'll be much less likely to be castigated by the individual who has to maintain your code after you. Microsoft has put Hungarian notation to rest, nobody else o speak of uses it, and you shouldn't either.
The type of Hungarian notation Spolsky uses at Fog Creek is different than the Hungarian once pushed by Microsoft. He goes over that in the linked article. I'm not defending it - I've never tried it - but it obviously works for Joel.
Also, if you're working at Fog Creek, the guy who has to maintain your code after you will also be using Hungarian.
The type of Hungarian notation Spolsky uses at Fog Creek is different than the Hungarian once pushed by Microsoft.
Hungarian notiation (of any variety) started (and ended) at Microsoft.
Also, if you're working at Fog Creek, the guy who has to maintain your code after you will also be using Hungarian.
If you're working at Fog Creek you're writing code in a custom in-house programming language as well as using Hungarian notation. I don't think the example is generally useful or applicable to anyone else.
int BugCount = Bug.Where(case => case.Id = caseId).Count();
(Where caseId is a parameter or something). It'd really simplify the API and keep you from doing safety checks on the SQL passed by the plugins. You might even be able to simply some of your "display" code to use Dynamic LINQ queries for the sorting and so forth.
I've been using the ASP.NET MVC + NHibernate + ActiveRecord + LINQ "stack" for several months now (though I've been an ASP.NET developer for about five years), and I have to say that my productivity has gone way up thanks to it.