Early in my software engineering career I was exposed to machine and assembly language programming. I find that fortuitous in that I was forced to be explicit; there are no cute constructs to fall back on when you're feeling lazy. Furthermore there is an implicitly enforced coding standard; I mean how many ways can you beautify mov cx, bx? Unfortunately the landscape gets increasingly muddied as you rise up the programming stack...

In higher-level languages you are abstracted sufficiently from machine operations - allowing you to focus on obtuse logic and visible components. And it is no surprise that there are many ways to jump not equals. With each representation comes advantages and disadvantages - and this is where considered coding practices are most valuable.

In Extreme Programming Explained, Kent Beck writes about this type of choice as programming values:

My friend Paul is a master gardener. I dig and plant and water and weed, but I am not a master gardener....Even if I knew all the same gardening practices as Paul, I still wouldn't be a gardener. Paul has a highly developed sense of what is good and bad about gardening. He can look at a whole garden and get a gut sense of what's working and what isn't. Where I might be proud of my ability to correctly prune a branch, Paul might see that the whole tree should come out. He sees this not because he is a better pruner than I am, but because he has an overall sense of the forces at work in the garden. I have to work at what is simple and obvious to him.

My current gig suffers from this "missing coding practices" condition. The code base is rife with a rich variety of bad habits - the result of many, many wannabe gardners tilling the soil. I was prompted to write about this after a brief conversation with a team member. We had been discussing the recent shift in Java formatting towards the majority-supported rules e.g. indentation, block-formatting, etc. Somehow the ternary operation came up...and the conversation turned into debate (I advocated a practice of restricting its use). It is a great little issue to point the importance of good coding practices. For some context, stop right now and follow this search stream.

If you are a programmer you likely used this operator at one point in your career - if not today. Setting aside good or bad - why do you use it? Convenience; habit? As a long-time C++ developer I used it because it felt cryptic...and I thought I liked cryptic. I also liked how I could cram more logic into one line...which fed my minimalist leanings. What changed? In my previous project - a green-field project - I was setting down coding standards, practices, and guidelines. During the review one of the project leads pointed out that I did not discourage use of ternary...and in fact was using it in my C# code examples. Being forced to debate it in a public forum was just what I needed; I could not form a reasonable justification for its use.

In fact this operator is a great metaphor. Its use signals the flouting of explicit intentions. It helps aggregate multiple decisions into one potentially nested line. It makes code review more difficult and is not a sustainable pattern across all programmers. To make matters worse, it is arguably less performant than the explicit alternatives. Take this line for example...how many code reviews and QE round-trips until this is caught?

Console::WriteLine(condition = 0 ? S"equality" : "inequality");