{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiguc22t3un4jaaqioz5qiqiv4wbjsn72og7k74x3zl5vkrlmxry6e",
    "uri": "at://did:plc:vyjlfm46mfv6u4vjp6qtrfx2/app.bsky.feed.post/3mgigczafbvd2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreidg2k33tiuupnstmiowh7hyyvtsbe3gyhfygiytrzynysnhoctrxi"
    },
    "mimeType": "image/jpeg",
    "size": 81260
  },
  "path": "/articles/qaudruple-negative",
  "publishedAt": "2026-03-05T06:30:00.000Z",
  "site": "https://thedailywtf.com",
  "tags": [
    "CodeSOD",
    "Advertisement] [Utilize BuildMaster",
    "Utilize BuildMaster to release your software with confidence, at the pace your business demands. [Download",
    "@c_usergroup",
    "@f_client_user"
  ],
  "textContent": "We mostly don't pick on bad SQL queries here, because _mostly_ the query optimizer is going to fix whatever is wrong, and the sad reality is that databases are hard to change once they're running; _especially_ legacy databases. But sometimes the code is just so hamster-bowling-backwards that it's worth looking into.\n\n**Jim J** has been working on a codebase for about 18 months. It's a big, sprawling, messy project, and it has code like this:\n\n\n    AND CASE WHEN @c_usergroup = 50 AND NOT EXISTS(SELECT 1 FROM l_appl_client lac WHERE lac.f_application = fa.f_application AND lac.c_linktype = 840 AND lac.stat = 0 AND CASE WHEN ISNULL(lac.f_client,0) <> @f_client_user AND ISNULL(lac.f_c_f_client,0) <> @f_client_user THEN 0 ELSE 1 END = 1 ) THEN 0 ELSE 1 END = 1 -- 07.09.2022\n\n\nWe'll come back to what it's doing, but let's start with a little backstory.\n\nThis code is part of a two-tier application: all the logic lives in SQL Server stored procedures, and the UI is a PowerBuilder application. It's been under development for a long time, and in that time has accrued about a million lines of code between the front end and back end, and has never had more than 5 developers working on it at any given time. The backlog of feature requests is nearly as long as the backlog of bugs.\n\nYou may notice the little date comment in the code above. That's because until Jim joined the company, they used Visual Source Safe for version control. Visual Source Safe went out of support in _2005_ , and let's be honest: even when it was in support it barely worked as a source control system. And that's just the Power Builder side- the database side just didn't use source control. The source of truth was the database itself. When going from development to test to prod, you'd manually export object definitions and run the scripts in the target environment. Manually. Yes, even in production. And yes, environments did drift and assumptions made in the scripts would frequently break things.\n\nYou may also notice the fields above use a lot of Hungarian notation. Hungarian, in the best case, makes it harder to read and reason about your code. In this case, it's honestly fully obfuscatory. `c_` stands for a codetable, `f_` for entities. `l_` is for a many-to-many linking table. `z_` is for temporary tables. So is `x_`. And `t_`. Except not all of those \"temporary\" tables are truly temporary, a lesson Jim learned when trying to clean up some \"junk\" tables which were not actually junk.\n\nI'll let Jim add some more detail around these prefixes:\n\n> an \"application\" may have a link to a \"client\", so there is an `f_client` field; but also it references an \"agent\" (which is also in the `f_client` table, surpise!) - this is how you get an `f_c_f_client` field. I have no clue why the prefix is `f_c_` - but I also found `c_c_c_channel` and `fc4_contact` columns. The latter was a shorthand for `f_c_f_c_f_c_f_contact`, I guess.\n\n\"f_c_f_c_f_c_f_c\" is also the sound I'd make if I saw this in a codebase I was responsible for. It certainly makes me want to change the c_c_c_channel.\n\nWith all this context, let's turn it back over to Jim to explain the code above:\n\n> And now, with all this background in mind, let's have a look at the logic in this condition. On the deepest level we check that both `f_client` and `f_c_f_client` are NOT equal to `@f_client_user`, and if this is the case, we return 0 which is NOT equal to 1 so it's effectively a negation of the condition. Then we check that records matching this condition do NOT EXIST, and when this is true - also return 0 negating the condition once more.\n\nHonestly, the logic couldn't be clearer, when you put it that way. I jest, I've read that twelve times and I still don't understand what this is for or why it's here. I just want to know who we can prosecute for this disaster. The whole thing is a quadruple negative and frankly, I can't handle that kind of negativity.\n\nAdvertisement] Utilize BuildMaster to release your software with confidence, at the pace your business demands. [Download today!",
  "title": "CodeSOD: Qaudruple Negative"
}