• Bogolese (unregistered)

    "There are CSS frameworks which disagree with me on this, but they are wrong." This makes me smile! :)

  • Ltrlg (unregistered)

    I'm feeling bad for that lonely divDownloadRebate!

  • (nodebb)

    Divide and conk out…

  • (nodebb)

    This comment will have a white background.

  • Kattman (unregistered) in reply to Bogolese

    this 100%. At christmas the marketing department will ask these be green and red because it's festive. Then your names lie. Give then names for their purpose, not their effect. Not to mention if you give them names for their effect, others will misuse them, or a grey background, exactly what I need for my button.

  • Peter Wolff (unregistered)

    To me, the anti-pattern

    variable = retrievingFunction(arguments) as VariableType;
/* stuff */ variable.memeber /* more stuff */

    is a code smell in C#: the as operator yields a null if the first operand is not castable to the second operand.

    Use either

    variable = (VariableType)retrievingFunction(arguments);
/* stuff */ variable.memeber /* more stuff */

    or

    variable = retrievingFunction(arguments) as VariableType;
if (variable != null) {
    /* stuff */ variable.memeber /* more stuff */
}
  • Beliar (unregistered) in reply to Peter Wolff

    The latter, with newer C# Versions, can also be written like this

    if (retrievingFunction(arguments) is VariableType variable) { /* stuff / variable.member / more stuff */ }

  • (nodebb) in reply to Peter Wolff

    Last week I saw a programmer cast all of the int? variables to (int) before using them. The change he was working on changed the variable from int to int? because we all realized there are a few business cases where the int was truly optional. He simultaneous added the ability to leave the int null and added a run time error if someone did so.

  • Scott (unregistered) in reply to Peter Wolff

    With the first example, you get an InvalidCastException if the result isn't castable.

    I use the second, but I'm reconsidering in some cases. Take the case of old-school .NET forms where you're searching for an element in a grid row when binding. If somebody changes the control's name, we only notice the binding quits working if we look at that. (Sure, one hopes that the developer changing the name tests that well).

    May be a case where an exception is preferable, to expose that issue. OTOH, how often do those name changes actually happen? So maybe not worth worrying about.

  • Anon E. Mouse (unregistered)

    Ah yes, the famous "If it's broken don't fix it" pattern

  • Scott (unregistered)

    Also, looks like it might be something from our code base, but I can't find which application it's in.

    I wonder why they care if each div is visible before adding to the collection. If some other operation makes the div visible, we'd want it to have the "right" class applied.

    Although I guess that using .Visible means we're not using client-side script to change the visibility of any div. During some postback which has the effect of changing visibility, we probably re-run this.

  • DrPepper (unregistered)

    Why? Just Why? This is what CSS is for. Css has built in capabilities to apply rules to alternating elements. Use HTML for what it was intended to do; use CSS for what it is intended to do. And for gods sake, don't muck around with HTML in C#.

  • Jay (unregistered)

    The case:

            else if (dDiv.ClientID.Contains("divDownloadRebate"))
        {
            Divs[j].Attributes["class"] = (j % 2 == 0 ? "GreyBackground" : "WhiteBackground");
        }

    Never gets hit because that control is not captured in the collection above.

  • Tim W. (unregistered)

    Or just use 2 lines of css to alternate the colors? https://www.w3.org/Style/Examples/007/evenodd.en.html

  • 🤷 (unregistered)

    Let's look on the bright side: At least the developer didn't use try-catch-blocks for controlling the program logic.

  • (nodebb) in reply to Scott

    Take the case of old-school .NET forms where you're searching for an element in a grid row when binding.

    That's easy to fix.... never do that. Create a viewmodel that does the binding logic and set the bound property of the UI element to the viewmodel property. This will turn your runtime errors into compile time errors (except for the data bound property, but that will runtime error the first time the first row is loaded into the grid). If you need special control behavior, create a custom control derived from the base class control.

  • tbo (unregistered) in reply to Tim W.

    Oh, good, someone beat me to it.

  • Peter Wolff (unregistered) in reply to Scott

    Of course.

    Anyway, if we risk something to go wrong (hopefully in a try block), the thrown exception should point to the location of the cause of the error and not to the location of the location where the error led to a failure. ("Worse Than Failure")

  • Naomi (unregistered) in reply to Beliar

    OT, but when I was a student I designed (but didn't implement) a language that worked like that - and also unified types and predicates. So eg. trying to get the head of a possibly empty list will fail at compile-time, but you can throw an if statement around it - inside the if statement, you know the list isn't empty and the compiler is satisfied.

    It was an interesting idea but had some really weird edge cases around mutable data and pointer aliases, and my solutions weren't particularly intuitive - in retrospect I should have looked into Rust, but didn't have time. Maybe I'll revisit it sometime, I dunno.

  • devils advocate (unregistered)

    This code is in the middle of refactoring, where they want to split the method into selectDivs() and colorRows()

  • (nodebb)

    The Codeless Code, Case 95:

    "...The monk replied: “In our shared stylesheet I have created a CSS class for this express purpose, named boldRedText.”

    Said Suku: “A most memorable name. Sadly, the provincial governor wishes his applications to promote a mood of tranquility. See that all warning text is rendered in a pale italic violet.”..."

  • mihi (unregistered) in reply to Tim W.

    You must be young if you never had to support IE8 in your apps (which does not support nth-child).

  • (nodebb)

    Much of the world is made up of bad backend presentational logic because either 1. CSS didn't yet support it, or 2. backend developers not know what's possible to do in CSS (they frequently are dismissive of anything frontend being "real" programming)

    All this mess is easily replaced with a couple of lines of CSS:

    .row {
  background: white;
}

.row:nth-child(2n) {
  background: grey
}
  • MiserableOldGit (unregistered)

    I've seen some awful while-switch, or do-select, or whatever implementations over the years. If Remy thinks that one is bad he really hasn't seen anything.

  • (nodebb) in reply to MiserableOldGit

    :topper: I've seen some awful try-switch and basket-case implementations over the years. If you think this is a jumping competition, you might want to adjust the suspenders of your pants.

  • MiserableOldGit (unregistered) in reply to Applied Mediocrity

    Boing ... boing ... boing.

    More that the real WTF is in the CSS use (which others have discussed). Yeah, it's a for-case pattern, but almost the least offensive example I ever saw.

  • (nodebb)

    :topper: I once saw CSS that had defined colors outside the visible color spectrum. When loading the page, I got a free CT scan.

  • Tim W. (unregistered) in reply to mihi

    Not really, I used to do this on the front-end in php with a counter++%2 back in the day. Some would argue that manipulating the color on the UI should be done on the front-end... but you could always use jquery on IE8 if you are hard-pressed for backwards functionality.

  • MiserableOldGit (unregistered) in reply to Applied Mediocrity

    They cost a chunk, stop complaining.

    If you can knock up a CSS script to get an MRI scan you are on to something.

  • (nodebb) in reply to dynedain

    Being blissfully unfamiliar with ASP.NET, I had to look it up and it transpires that the .Visible property actually prevents the control's HTML from being generated and sent to the browser. (If the elements were still present in the DOM then the CSS approach would not have worked.)

  • Adam (unregistered) in reply to Scott

    You're thinking of a cast expression: "(type)value" Those throw InvalidCastException. The "as" operator will return null rather than throw InvalidCastException.

Leave a comment on “It's For DIVision”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article