Jan
24
Fuck DAT
Filed under (Cubicle & Campus) by The Cubelodyte on January 24, 2006 @ 09:25 pm

The database application our division produces has, of course, a lot of different reporting tools built in to it. It would, after all, be pretty useless if it didn’t have the ability to cough up wet wads of student data on demand. One of the reporting features is this concept called "Data Access Tags", or DATs. These are little bits of code that customers can embed in their reports to dynamically pull data so that you can do things like print report cards and have Johnny’s grades show up on Johnny’s report card.

The other day one of my irascible colleagues and I were commiserating about what a pain in the ass some of the DATs are. Many, if not most of them, were written in the Bad Old Days when our division was a completely independent company (long before they were purchased by Apple), when the development model would have been handily summed up as either "a couple of guys dicking around with source code" or "let’s add every feature suggested by every user". Dealing with legacy code is never much fun, especially if the jokers who wrote it didn’t bother to, oh, say, write anything down.

So anyway. We were talking about these DATs, and one of us (I don’t remember who) mumbled the name of one causing problems, to which the other responded, "What? Which code?". At just that moment, a third colleague, in response to some different but equally irritating problem, exclaimed "Fuck!", and thus was born the "fuck" DAT.

So, without further ado, here is ^(*fuck). It’s funnier if you understand PowerSchool, but it’s still worth a cheap laugh even if you don’t. Or maybe it isn’t. Ah, who gives a ^(*fuck).

Code Usage
^(*fuck;param.option) ^(*fuck)is usually used to declare a temporary cessation of cognitive processes or denote a general exception. Overuse of ^(*fuck)in production environments can cause problems with currently instantiated objects of the coWorker class, and prematurely terminate Job().

^(*fuck) may be passed any one of the following eight parameters:
!, you, me, it, this, her, him, and them.
The .option subparameter construction is largely deprecated, but is still functional.

Parameter Syntax Notes
None ^(*fuck) Used without parameters, ^(*fuck) indicates an general error state.
! ^(*fuck;!) The ! parameter is used to mark the halt of processes due to a particularly critical or unexpected error.
you ^(*fuck;you) you is used to assign blame to the instance of coWorker on which hate() or blame() is currently being called.
me ^(*fuck;me) Passing of the me parameter generally occurs at the end of coffeeBreak() when evaluateWorkLoad() is called. The deprecated parameter construct me.running is rarely seen today, though once widely used.
it ^(*fuck;it) Used to indicate an irrecoverable error state and the termination of all active threads. The optional .all subparameter is assumed when it is passed to ^(*fuck).
this ^(*fuck;this) Also used to indicate irrecoverable errors. Depending on the context it is used in, this is often confused with the functionality of it, but this generally refers only to the function currently being executed. Other concurrent threads may continue to execute normally.
her ^(*fuck;her) Used when passing the results of coWorkerA.hate() or coWorkerA.blame()to coWorkerB (or multiple other coWorker instances), when the gender value of coWorkerA != male. In some circumstances, this may be used in conjunction with attempts to use coWorker as a Sex object. This generally results in the immediate termination of Job().
him ^(*fuck;him) Used when passing the results of coWorkerA.hate() or coWorkerA.blame()to coWorkerB (or multiple other coWorker instances), when the gender value of coWorkerA = male. Unlike with the her parameter, the coWorker can usually be used successfully as a Sex object.
them ^(*fuck;them) them is used as with her and him, but when the number of coWorker objects for which hate() or blame() is called is unknown or unspecified.

I hope you enjoyed this little lesson. This handy information will also be sent to our customer base in the general release notes for the next version of our application.

 


You must be logged in to post a comment. Don't have an account? Register!