• (nodebb)

    While we're bitching about names ...

    The class name of the parameter object named order is CreateOrderRequest. When you're naming your objects which represent nouns using verb phrases, there's something damaged between your ears.

    And what business item does that object represent? An order, a request, a request to create an order? Whatever it is, order is almost certainly a bad name for a parameter representing one of them.

  • Darren (unregistered)

    I very much dislike ternaries. They always strike me as a developer-being-oh-so-clever thing. I'd much rather have them split out as an if-else so that their meaning is absolutely clear to whichever poor soul has to look at the code in the future.

  • (nodebb)

    The thing I dislike about ternaries is the scope for showing off your ability to be cryptic and lazy at the same time.

    Case in point, this sample I found in a codebase almost 30 years ago (and the context is important...):

        if ( condition_one )
        condition_two ? variable = value : 0;
    else
    {
        some();
        other();
        code();
    }

    Too lazy to put braces around the inner if() ???

  • Hans (unregistered)

    Plus the fact that order.GetOrderParams() is called three times, two of which use .getOrderType() on the result.

  • (nodebb)

    Sure it's not short for ORDURE?

  • (nodebb) in reply to Darren

    +1 for spelled out if else then. My brain does not parse code like from the tape of a turing machine, but sees the pattern/structure like Ifs.

  • Tim Ward (unregistered)

    Ah, the constant name things, they're fixed width fields, dating back to when the data entry was done with punched cards.

  • (nodebb)

    The abbreviations could be from another system, so you could recognize where the values came from.

  • (nodebb) in reply to WTFGuy

    The class name of the parameter object named order is CreateOrderRequest. When you're naming your objects which represent nouns using verb phrases, there's something damaged between your ears.

    And what business item does that object represent? An order, a request, a request to create an order? Whatever it is, order is almost certainly a bad name for a parameter representing one of them.

    Almost certainly a CreateOrder HTTP request. Do you have a better suggestion for what to name the class? Sometimes there are no good options, so you go with what you think is the least bad. See also the second hard problem in computer science.

  • Brian (unregistered)

    I'm not too bothered by ternaries, if they're not trying to be "clever". Simple statements for assignments or returns are convenient, especially in places where a whole if/else construct would actually hinder readability. But I was happy when C# added the null-conditional and null-coalescing operators, to eliminate an entire class of these things.

  • (nodebb)

    It really can't be that much more work to write this instead:

    private static String getOrderTypeCode(CreateOrderRequest order) 
{
    var result = ORDR_TP_DQQ_BAR_CDE:
    var params = order.getOrderParams();
    if (StringUtils.isBlank(params.getReceivingCompanyFoo()) || ORDR_TP_DQQ_FOO.notequals(params.getOrderType()))
    {
        result = params.getOrderType().getOrderTypeCode();
    }
    return result;
}
  • 516052 (unregistered) in reply to WTFGuy

    Your complaint kind of makes sense in a vacuum. But it ignores the fact that any sufficiently complex system is going to naturally develop a set of conventions, written or implied that dictate the patterns used to name things. So whilst this might be ambiguous to you without the context of the system it is written for anyone familiar with said system will most likely have no ambiguity at all as to how to interpret it.

  • (nodebb)

    I agree with what many of you say about ternaries in general, especially in the wild, but I do feel they can have a place, especially when each operand is short:

    var orderParams   = order.getOrderParams();
var orderType     = orderParams.getOrderType();
var companyFoo    = orderParams.getReceivingCompanyFoo();
var orderTypeCode = orderType.getOrderTypeCode();

var isFooOrderType = !StringUtils.isBlank( companyFoo ) && ORDR_TP_DQQ_FOO.equals( orderType );

return isFooOrderType ? ORDR_TP_DQQ_BAR_CDE : orderTypeCode;

    Though I also like @dpm's approach above.

    Addendum 2026-01-15 11:04: Probably should have put var orderTypeCode = ... above var companyFoo = ...

  • ricecake (unregistered) in reply to gordonfish

    Ternaries need to be used if you are initializing a read-only variable whose value depends on a condition. Also, I find this formatting for nested ternaries to be pretty readable:

    var x = condition1 ? value1
      : condition2 ? value2
      : condition3 ? value3
                   : value4;
  • (nodebb)

    So, Remy, you're not a fan of disemvoweling words?

  • Duke of New York (unregistered)

    Why not write conditionals that wrap across three lines, so long as you do wrap them?

    Aversion to conditionals is a solid mark of a timid developer.

  • Angela (unregistered) in reply to 516052

    If that was the case, I don't think it would have been submitted to this site in the first place.

  • (nodebb)

    @dpm I like a lot of what you did there. but it amounts to this pattern that's notso hotso

    var result = // assumed rare special case value
 // set temp vars to avoid repeated property chain chasing 
if (situation is not the special case)  {
    result = // base case
 }
return result

    I agree it's nice to avoid syntactic negation in the predicate of the if. But if the result of doing that is semantic negation spread across several lines all of whic are assuming the special case is the common case, I think we threw out the baby and saved the water. In your case we ended up with both. IMO much better to always arrange this pattern like

    var result = // assumed base case value
 // set temp vars to avoid repeated property chain chasing 
if (situation is the special case)  {
    result = // speecial case value
 }
return result

    This latter form also extends neatly if there are multiple special cases, whereas the former does not.

Leave a comment on “A Sudden Tern”

Log In or post as a guest

Replying to comment #690004:

Log Out

« Return to Article