In my daily browsing of topics, I stumbled across a conversation on ‘coined programming jargon’. The conversation is well on it’s way to go beyond the 8 pages and appears to have started somewhere in or before February. I’m not sure how I managed to miss this one, but the terms coined are quite amusing. I might just have to go and start using them in my projects for when I need a lift.

Here are my personal favorites…

  • Pokemon Exception Handling – For when you just have to catch em all.
  • Yoda Conditions – The act of using if(constant == variable) instead of if(variable == constant), like if(4 == foo). Because it’s like saying “if blue is the sky” or “if tall is the man”.
  • A Duck – A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.
  • Hindenbug – A catastrophic data destroying bug.
  • Bloombug – A bug that accidentally generates money.
  • Schrödingbug – A problem that some people see when they look and others can’t find at all. Often tied to the execution environment in a surprising way (or a cat).
  • Heisenbug – A computer bug that disappears or alters its characteristics when an attempt is made to study it.
  • Barack Obama – An [account or queue] that we assign our most aspirational tickets. Like stuff we’d really like to do with a project but will probably never get approval for.
  • Fear Driven Development – When project management adds more pressure by firing someone or something else of similiar shock factor.
  • Higgs-Bugson – A hypothetical bug predicted to exist based on a small number of possibly related event log entries and vague anecdotal reports from users, but it is difficult (if not impossible) to reproduce on a dev machine because you don’t really know if it’s there, and if it is there what is causing it.
  • Chunky Salsa – A single critical error or bug that renders an entire system unusable, especially in a production environment.
  • Hooker Code – Code that is problematic and causes application instability (application “goes down” often).
  • Hydra Code – Code that cannot be fixed. Attempts to fix any single bug will causes two new bugs to appear. In the end, it should be rewritten.
  • Ninja Comments – Comments that doesn’t exist in code where someone would normally find them
  • Code Slush – The date after which no changes will be accepted, except of course, all the changes that management will ask for at the last minute. Like Code Freeze but accepting of the fact that some changes will still get in.

Update 9/15/2014: Link is now dead, so it’s just you and me now. If you know about a longer list of these somewhere, let me know.

I thought I might talk about my pre-blogging days of trying to learn PowerShell when I was trying to avoid learning the VBScript language (I don’t care much for the synatic qualities of the language).

I personally love the PowerShell language as I’m familiar with both C# and PHP, and (at least to me) it looks like a bastard child of the two. The creation and intialization of objects or variables are done the same way as in PHP and has the same method and property accessors that you’d come to recognize in C#. It took me about an hour to pick up the basics of the language, but I just needed to learn how to create classes so I could start causing some damage.

Unfortunately one of the lacking items in PowerShell, even after version 2 is the lack of native classes. The strength of the .NET framework has always been behind the PowerShell language, but it’s never been directly accessible unless you’ve built cmdlets that allow you such power, so your reliance on custom classes have required you to compile them using Visual Studio. Until such time comes around, there are at least a couple of workarounds.

I had pinged a few people around Microsoft to see if it might be possible after reading this blog entry regarding the CTP3 release of PowerShell v2 if the method in how one would dynamically compile C# code into an console application could be used in other ways. It evidently wasn’t quite clear from the original post, so James Brundage from the PowerShell team posted this blog entry showing how you can use the same technique to compile C# based classes on the fly in a script. Pretty neat!

If you’re not a blogger, but know PowerShell pretty well, let me know about any hidden or not-so-known tricks in PowerShell that you know of and I can make an entry for you. Credit will be given!