• Rob (unregistered)

    Of course, like any ternary expression that returns a boolean, both can be rewritten using just boolean logic. Simplified:

    ColHectarias.Visible = Dist_Por == TIPO_DIST_COSTO.Hectáreas || Dist_Por == TIPO_DIST_COSTO.CCosIndirecto;
ColPorcentaje.Visible = Dist_Por == TIPO_DIST_COSTO.Plantilla;

    I could leave out the starting ternaries of the first one because there are only two true outcomes.

    Similarly, I could leave out most of the ternaries for the second one because there is only one true outcome. Everything after that true results in false. I'm guessing that there should be a true in there somewhere.

  • (nodebb)

    Wtf.Visible = false == Me.IsFrist ? false : true

    Addendum 2026-01-28 08:33: Although in today's case the WTF is all too visible.

  • Supernova (unregistered)

    TRWTF is not handling FileNotFound

  • Argle (unregistered)

    ¡No hablo c#!

  • Álvaro González (github)

    Bonus points for using accented words as identifiers (TIPO_DIST_COSTO.Hectáreas). I've worked many years with Spanish language codebases and I've seen all kind of horrors and idiosyncratic choices, but nobody ever had this particular idea.

  • Java Apologist (unregistered)

    This code is reasonably clear once you add line breaks, but then it just becomes obvious that it should really be a switch.

    And by "reasonably clear", I mean "holy hell these variable names are killing me".

  • A Human (unregistered)

    Of course there's some hungarian notation sprinkled in there as well.

  • Kotarak (unregistered)

    TRWTF is that the constants are hardwired into the code. The valid flags should be put into a set and the test to show the columns should just check whether the provided constant is contained in the corresponding set.

    The set may be reused at other places where necessary and - should the need arise - can be read from configuration at runtime.

  • 516052 (unregistered) in reply to Álvaro González

    I once inherited C# code where the variable names were cyrllic.

  • Conradus (unregistered) in reply to 516052

    What would be really fun is Hebrew or Arabic. 'Cause having variable names that read right to left is neat!

  • (nodebb)

    The day I read this I used a nested ternary at work. While I do think mine was much more readable and justified, I still felt guilty about it given what I had just read.

  • (nodebb)

    Possibly ColHectarias was so named because the original author was singing a merry tune. About what, I hate to think, admittedly, but variable names have been chosen with less logic from time to time.

  • (author) in reply to Conradus
  • (nodebb) in reply to Álvaro González

    <tryna_be_funny>I know it's such a cliché, but as I mentioned in my résumé, I'm so happy that English doesn't use accented letters anywhere. Let's stop being so naïve and create some façade to protect us from the evils of special characters. </tryna_be_funny> <rant> But seriously even plain old ASCII caters for most of those in the English context, but TRWTF is us still struggling with funny characters in 2026. I thought the problem was solved with Unicode. No, wait... </rant>

  • 516052 (unregistered)

    I'll give you 3.50 for the lot. And not an chon more.

  • MaxiTB (unregistered) in reply to DonaldK

    Should have gone with "über evil" instead ;-)

    However there is a valid reason why English should always be used for source code: Every programming language is in English and nothing is less readable than mixing multiple languages with often completely different grammar together.

    And I know DDD evangelist are now shocked, but lets face it, the whole idea of using business terms in your code is flawed cause often they arent well defined. I remember I once had a client with six definitions for location... seven actually, they invented a new one that had nothing to do with the others to have a universal definition. The truth is defitions of business terms are often on purpose vague to avoid responsibility. And that doesnt work in computing.

  • Kotarak (unregistered) in reply to MaxiTB

    The problem is not having seven definitions for "location". That's just reality. The problem is nameing each of them "location". That brings the problem. We have for example "production location" and "delivery location", which might be different. Then we have a logical "quality responsible location" on top, which depends on what the "delivery location" actually is.

    Then you have the sales department which has locations. Their locations have things like "Location A plant" and "Location A HQ". Both "locations" are in fact physically in the same place and even share office space. However, their are different in the business logic of Sales.

    So it is the unfortunate job of the interface between code and customer to come up with mutually agreed names and contents for all these things. Yes, just using "location" doesn't cut it. And I think this what the DDD stuff is about.

    (I had a data export with five columns called "date". Luckily I could derive the true names from the contents.)

  • (nodebb) in reply to Kotarak

    Then you have the sales department which has locations. Their locations have things like "Location A plant" and "Location A HQ". Both "locations" are in fact physically in the same place and even share office space. However, their are different in the business logic of Sales.

    That sounds more like there being a potential for "Location A plant" and "Location A HQ" being two separate locations if one of them is ever moved to another place, which is not unheard of. In such an event, you don't have to add a new field for the new location, just update one of the individual existing ones.

Leave a comment on “A Field Terned Visible”

Log In or post as a guest

Replying to comment #690591:

Log Out

« Return to Article