• (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.

  • (nodebb)

    I'm a bit flexible on ternaries, but I hate the conditional analyzers Microsoft has added for them to C#. I have been known to write parse methods where we need specific errors as a sequence of if (condition) throw new FormatException("condition-specific error"). Whether it's 2 or 12 lines, the analyzer wants to just keep stacking ternaries until it finally hits a line that can't be added in. I actually took its advice once, just to see what would happen. I know there are those that oppose early-exit and would want curly braces on the ifs, but trust me...no matter how bad you think my original code was, it was not improved by turning it into a return followed by 5 stacked ternaries with only the final one containing a value. The value to be returned on success was 11 lines below the return keyword. There's no way to set a limit on line length or number of lines in the recommended conditional; it's either leave it on and greedy or turn it off completely.

  • 516052 (unregistered) in reply to Angela

    Not necessarily. Over the decades I have encountered many projects and found that the most rancid ones also tend to look the best on the surface. "Bad" project with lots of mismatched names, no coding conventions, large files etc. tend to be bad in a predictable and pedestrian way.

    But the truly bad ones don't look like that. No, they look good. They tend to have good code conventions, perfect naming structure and generally look professional. They work just good enough too that you think little of taking a look inside. But the moment you dive beneath that surface you find that the much like the tranquil beauty of the ocean the depths conceal horrors beyond imagining.

  • (nodebb)

    (replying to gordonfish) I wrote my code that way specifically to avoid what the original code avoids: calling getOrderType() and getOrderTypeCode(). I don't know what those two {functions,methods} do, so I won't invoke them until they're necessary. They might cause a slight performance issue, they might throw an exception, they might return invalid values. When ignorant, I bulletproof.

    (replying to WTFGuy) My reasoning applies to your analysis as well: while awareness of patterns is certainly good & proper in general, this is a seven-line refactor of an unreadable ternary, not an abstract theory. What you call "the base case value" may well involve more work than a simple string assignment, so I'm not gonna do it in this particular case and I feel justified in doing so, since it is a very small function and what is happening is quite obvious.

    Addendum 2026-01-16 09:09: You're also making an assumption as to which return value is "rare" and which isn't --- but that cannot be determined from the given code.

  • (nodebb) in reply to dpm

    @dpm Yes you make a great point; there could always be some side effect that could be unwanted in some conditions, though in my experience, especially with get*() functions that should only be returning information and shouldn't have side effects, but as a long time reader and programmer, there is definitely no guarantee of that :) So your points are well taken, including about rare vs common cases which I agree cannot be determined from this article's snippet.

  • MaxiTB (unregistered)

    I think the lack of Java's property support with all those verbose setters is actually worse than the ?:.

  • MaxiTB (unregistered) in reply to Darren

    Conditional operators allow thanks to their functional nature better compiler optimization than regular conditional statements. They are especially import in the context of tail optimizations.

    However I understand why people don't like them. First there are languages especially in the Java family which (to my knowledge) threat the operator like a statement due to flaws in the byte code specs. Secondly ever good feature will get a bad rep when there are person abusing or not understanding it. Other good examples are null & goto.

  • Old Timer (unregistered)

    "ORDR is short for ORDER. CDE is CODE"

    I worked with end-users doing scripting. My simple advice to them was 'never use a dictionary word for a variable. All the dictionary words you want - date, time, name, record, file, order, first, last, whatever -- are already taken by the system, and will just cause confusion'

  • Craig (unregistered)

    Given the context, I could imagine ORDR being part of a family of four-character identifiers (presumably involving at least one word of only four characters), then the family of constants would get a nice visual sort.

  • Gilbert (unregistered)

    FULLZ UPDATED 2026 USA UK CANADA SSN NIN SIN INFO with ADDRESS DL Photos front & back with Selfie Passport Photos IT|SP|RUS|AUS|BR|FR amny Countries DL photos available

    Children FUllz USA 2011-2023 Young & Old age FUllz 1930-2010 High CS Pros 700+ Comapny EIN Business Fullz LLC EIN Docs with DL Dead Fullz CC with CVV & Billin Address

    NIN Fullz with Address NIN Fullz with address Sort Code & Account number NIN UK Fullz with DL UK DL photos front back with Selfie UK Passport Photos UK CC fullz

    SIN Fullz with Address Canada DL Photos Front Back with Selfie CA Passpoprt Photos CA Email & Phone Number Active Leads Live CA Fullz

    Germany|Spain|Australia Fullz with Address & DOB Email Leads (Forex, Crypto, Casino, Investors, CEO's, Crypto, Crypto Exchanges) Sweep Stakes Active Combos & B2B Leads

    Tools & Tutorials available Carding Cash Out Scripting Spa--mming SMTP RDP C-panels Shells Web-Mailers SMS & Email Bulk Senders Look-Up Tutorials

    Telegram@killhacks - @ leadsupplier What's App - (+1) 727..788..6129 TG Channel - t.me/leadsproviderworldwide Discord - @ leads.seller VK Messenger - @ leadsupplier Signal - @ killhacks.90 Zangi - 17-7369-4210 Email - exploit.tools4u at gmail dot com https://about.me/gilberthong

    Many Other Stuff available in our shop Active & Live Fullz with guarantee Providing Replacements if anything found invalid Available 24/7

    #fulz #leads #emailleads #sweepstakes #cryptoleads #casinoleads #ssnleads #dlphoto #usaleads #canadaleads #fullzusa #fullzuk #whatsapp #facebook #activeleads #ccshop #cvvdumps #usadocs #highcreditscorefullz #eincompanydocs #kycstuff #infokyc #validfullz #validvendor

Leave a comment on “A Sudden Tern”

Log In or post as a guest

Replying to comment #690689:

Log Out

« Return to Article