Throughout my career, it's been rare to be on a project where I am not asked for some sort of software estimate. No one likes estimating but I am diligent and do my best estimating how long developing something that I've never done before will take. But how are these estimates used? One common thing I've seen is taking an hour estimate multiplied by some constant to determine the "project cost". The constant is usually based off of loaded salaries and number of people involved. That dollar amount is not the cost of the project. It isn't that this number is off by some kind of factor, it is that it is almost unrelated.

So let's ignore the common issues when estimating. Ignore calendar time vs working hours time. Ignore staffing changes or priorities changing. Assume the features will be added in such a way to not accumulate technical debt. Let's assume the time estimate is 100% accurate (which happens 0% of the time). Can you now multiply it by a constant to get the cost? Nope!

Software's True Cost

The obvious issue with this cost estimate is that hours isn't how salaries work. Software engineers are usually salaried. You pay staffing costs whether you take on a new project or not. You still have to pay them even if you give your engineers nothing to do. It also doesn't go up if they work overtime (usually exempt from overtime pay). Your cost isn't in hours. This is different for contractors, hourly employees, or companies with lots of turnover. But generally it isn't the case where you can decide not to do a $100K project and then have $100K left in the bank. Maybe if a project is 100% outsourced this can be close to true; there are always costs regarding managing the project internally though.

This gets into the issue of opportunity costs. Your staff probably won't sit around idle if you don't give the go ahead for a project. There are always other projects or features to do or to help with support or clean up technical debt. There is always more things to do than time. People like contributing and will do the best they can to make a difference. Unless you can massively change the number of staff you have quickly, taking on one project means you won't be doing any number of other projects in the same time. Delays, scope reduction, or cancelation of other work is part of the project cost. I've been on a project providing a prototype / demo for something that would never be sold to anyone that left important and profitable work being delayed. That project cost a whole lot more than the wasted hours. Our main product was neglected during this time and we weren't in nearly as strong of a market position as we'd otherwise be. Whoops!

Ongoing Future Costs

But probably the biggest factor in a project's cost is not the initial cost but future costs — and I don't mean fixing the bugs you missed. While software design and source code are considered engineering details, they have a massive impact on the overall organization. If you asked me to add a feature to one application and to add the exact same feature to a totally different application, how long it would take would vary greatly. This is due to overall system structure, non-functional requirements, what other needs the software meets but also software complexity.

Complexity doesn't grow linearly. As an example, take an application with 4 different on-off settings. The possible number of setting combinations you could have is 16. If you add a new setting now you have 32. But if you do the same thing to an application that has 10 settings, you've just added 1024 more possible combinations! This is a simplistic example but it has a profound impact in software development. Software complexity makes everything harder. It is harder for engineers to understand and work in. It is harder to test. There will be more bugs and surprise edge cases. Technical support is harder. Complexity is very expensive! Any time you add a feature, change a requirement, fix a bug, you are usually increasing the software complexity.

So unless you are just doing billable work for a customer where the customer pays the entire software maintenance cost, the cost of complexity is yours to bear. But don't worry, it gets worse than that. As your software gets larger and more complex, you'll have to increase staff. More people means communication becomes more difficult. You have more people who have to communicate with each other and miscommunications will be more common. You'll have more coordination costs and management costs for more staff. You will be paying the cost of a 2 week project years later.

There are likely even more aspects of software development costs that I haven't addressed. What is important to realize is that these costs are far more significant than the number of hours it takes to do a project. Project timelines matter for all sorts of things between making commitments to customers or investors, planning out when to do what, and prioritizing work. But the number of hours doesn't tell you much when it comes to knowing what a project will cost.

Don't Forget About Profit

With all these gotchas when it comes to software cost, one thing is quite evident; developing software is very expensive. This is why it is important to do proper analysis on features and projects. Work on things that are valuable to all customers. I've been on a number of projects that have been canceled or cut short. This is incredibly expensive. One of the most expensive things you can do is to tell developers to just "make it all work". You have to prioritize.

So it is understandable to care about software costs and to look at these details. But it is a mistake to just take hours, multiply by some constant, and then compare it to expected revenue. Managing a business is much harder than that.

The upside is that the benefits of software can be way beyond the initial project too. A project that might be for one customer could potentially be sold to other customers. Or maybe it could be modified in a future project to be more generally useful. This is the business of software; develop it once, sell it everywhere. So if you are developing a product and you really need to know exactly the cost to know if it will be profitable, then you are in a very bad position indeed. It means the amount of profit you expect to get from it is very limited. Maybe consider a different product or approach.

Everyone likes to joke about how they don't use any of the stuff they learned in college. This isn't the case for me. There is some I use and some I don't. One thing I learned pretty well is how to simplify expressions and reason about boolean algebra. I use this most days in programming to verify that my code is correct and to simplify expressions. One common trick I use is to distribute a negation operator to an expression using De Morgan's theorems in order to cancel part of it out. Very handy!

What math won't tell you is why is code the way it is; what is the intent the programmer had while writing it. While maintaining and modifying code I sometimes run across some very complicated logic. Maybe this is a large "if" statement with lots of terms or nested "if" / "else" blocks. There is only so much boolean algebra can do to simplify this. Sometimes code is complicated because the problem being solved is complicated.

Example

if (features[var1].status == 'e' && ((uid == '0' && config.env == 'l') || 
user.flags.indexOf('call2') >= 0) && !(settings.flag2 || status == 3)) {
}

This code's boolean logic is actually pretty simple. But to understand code like this you have to understand the context. What do these variables mean, where is it used?

Once you figure this out, here are my tips on how to make the code easier to understand for both yourself and other programmers. Certainly you should consider boolean algebra to simplify any complex expressions. Also consider naming the magic numbers here too. But you should also name the subexpressions.

Subexpressions

const isFeatureEnabled = features[var1].status == 'e';
const isRoot = uid == '0';
const isLocalEnvironment = config.env == '1';
const isUserEntitledToCall2 = user.flags.indexOf('call2') >= 0;
const isSpecialCustomer = settings.flag2;
const isServiceDisabled = status == 3;

Try not to get hung up on the naming convention here. Some people like more terse names, some like it more spelled out. The point is to give names to these expressions by assigning them to a variable. Another possibility is to extract some of them to a function. This is naming it too.

function isLocalEnvironment(config) {

Now we can put all these named subexpressions back into the conditional.

const hasPermissions = (isRoot && isLocalEnvironment(config)) || isUserEntitledToCall2;
if (isFeatureEnabled && hasPermissions && !(isSpecialCustomer  || isServiceDisabled )) {

Notice I added another variable for part of the remaining expression. Here hasPermissions is introduced to simplify the permission check.

Is this code right or wrong? That's always difficult but by naming these subexpression we now have a chance to analyze it. First we see if all the variables are checking the values they should. The definition for "isServiceDisabled" seems suspect. Maybe there are other statuses that are possible that should be checked. Or maybe it is ok. The point is we can check small parts of it without mental overload.

Then we can also check the main "if" statement. Are the "and"s and "or"s and "not"s right? That too can be checked piecemeal.

Comments

I'm never going to object to adding more comments to code. It is rare to encounter code that has been well documented. So it wouldn't be a bad thing to add comments to the "if" statement as well. But it is better to simplify complicated things than to document it. Add comments for knowledge that the code doesn't immediately provide.

Extremes

In my career I've met engineers who thought unit testing was a waste of time. They thought it took too long to write, didn't catch all that much, and was busywork. This is a bad dismissive attitude. You must try a practice and give it a chance to see where it works best. As developers we have powerful computers at our disposal, it isn't a good use of resources to manually poke through code for every release to test it. Computers are good at this sort of thing.

I've also met engineers who were at the other extreme. All code must have unit tests, target 100% code coverage, or maybe write your unit tests first. This also is crazy. Not all code equally benefits from unit tests. You are better off concentrating your efforts on unit testing code where you get the most value than to try to do everything. I've never worked on a project where everything was specified ahead of time to be able to write tests before code. Engineering is generally more fluid than that. If you are working on a strict waterfall maybe this is possible, but that sounds like a terrible project to be on.

What Works Well

Algorithms and data structures often benefit from unit tests. It is great when working with a reversible algorithm as it is a simple test write to apply and reverse and can catch a great number of problems. Some algorithms are very complex to solve a problem but also very simple to check. Algorithms and data structures tend to be more isolated code. They don't generally depend on your database server, some web service, or operating system calls. So, there isn't much work needed to test them in isolation.

Really any problem that you can throw a ton of data at it and can validate its behavior with the data works well for a unit test. From a single unit test, you can try a large number of conditions.

For one project I had to design an algorithm that would significantly change the data storage format of what was essentially simplified program code. Unit testing worked well on that. Give the algorithm different scenarios and make sure it handles them ok. Apply the transformation and reverse it and verify that it reverses ok. This found a ton of bugs out of a small list of unit tests.

What Doesn't Work Well

Sometimes the kinds of problems that introduce the largest number of bugs also are the hardest to unit test. Integration with another software system or with hardware often behaves vastly different than you think it will or has been specified to behave. These kinds of bugs tend to show up when code is moved to production, and you probably won't have logging around the unexpected integration behavior because it is unexpected.

What is or isn't integration testing vs unit testing isn't something everyone agrees on. But a common technique for isolating modules is to mock out the integration points. The same assumptions you made when writing your code will also be put into the mocked objects and unit tests. You are then testing that your code handles the way you think the integration behaves and not how it behaves. This can catch some issues, but the most difficult bugs that it would be great to catch slip through.

These kinds of bugs of missing information, false assumptions or not realizing something could behave a certain way are quite expensive. Unit tests may catch them by accident or when working on unit testing you suddenly realize something could happen. But in general, they aren't great for this.

Don't Only Do Unit Testing

One bug I had to deal with that was very frustrating was in an interrupt handler for a input pin. On occasion, my microcontroller would just reset (probably watchdog or other check). I eventually traced it down to the timing of the input pin. The code I was running was a scripting language and the interpreter would fail out it the interrupt was triggered faster than it could run the script. This failed for even an empty interrupt handler.

This is an obvious case where unit testing won't catch the problem at all. Mock out an input pin? Well, the mocked code would always work. It wasn't a code logic issue, the problem happened even when the interrupt handler was empty.

This may seem obvious, there are many more QA practices than unit testing because there are all sorts of bugs in software. The best way to mitigate bugs is through multiple approaches. Don't spend so much time on code coverage and unit tests that you don't get to other forms of testing, review, or QA practices. Depending on the project you are working on, maybe the other QA practices are more valuable. Every project is different.

100% of code coverage also isn't a good target. How many possible states are you testing? Are edge cases covered? These kinds of problems are hard for your brain to think about at the same time and more likely to have bugs. If you are concerned about validating every line of code, it is better to use code reviews for that.

Use Your Debugger

I've seen an odd mentality in software developers lately that there is a view that using a debugger is lazy and you should be unit testing and using logging. This seems to go along with the increase in cloud computing where debugging a running application is either difficult or simply not possible.

Yes, write unit tests! Yes, use log files! But a debugger is a wonderful tool to find bugs! Learn your debugger well. Hopefully it has something like a REPL where you can execute code snippets while you are running your program. Avoid development tools or languages that don't have a good debugger. Shipping code because the unit tests all pass isn't far removed from shipping code because it compiled. Great, it can catch some things, now finish testing it.

Sometimes it takes looking at a scenario in a debugger for the actual cause to be apparent. Code is complex, it is hard to keep all the possibilities in your head. This is even harder when digging through logs or writing unit tests. Sometimes it really helps to see what is going on.

Including Managers

Including managers in a peer review is probably the most common mistake I've seen. The downsides aren't obvious and sometimes including management just feels like the right thing to do. Having managers in code reviews is very tempting for many reasons. One common concern managers have is trying to keep track of how a project is going, what work is in progress, and how well their engineers are performing. Code reviews sound like a great way to accomplish that. Also, code reviews can bring out different team problems and personal conflicts so it is understandable for managers to want to be involved in order to monitor and deal with them.

Theses reasons are legitimate and understandable but they also make code reviews much less effective. There are plenty of other ways managers can look at team performance and the system source code. As the primary focus of a review should be finding bugs, anything that gets in the way of that needs to be avoided. Code reviews can be expensive as it includes several other engineers to look over each other's work. It is important to make them as useful as possible.

Having managers in a review meeting transitions it from a honest evaluation to a situation where making a good impression matters. It could be said that engineers should be professional and shouldn't think like that, but I don't think that is fair. Human behavior is surprisingly predictable. We often behave different in front of authority or someone important than how we behave otherwise. Just like how professionals don't air their dirty laundry in important meetings or in public, engineers are careful about what they say in front of management in review meetings as well.

It can be daunting to go through code review. The author of the code likely spent days or weeks working to get things right and everyone else is trying to pick it apart. If this is done in front of his / her manager, this can create a perilous situation. Even if everyone has the best intentions, presenting flaws in someone's work in front of their manager can go over very badly.

So one thing I've seen myself do in code reviews is tell the author about defects outside of the review meeting. This was when I found a simple / dumb mistake that I thought would look bad. This isn't good process because it should be a team effort to look over defects found and analyze them. But reviews should be about the positive effort of making the work better and I didn't want embarrassment to be part of the process.

Another problem that can happen in review meetings is to nit-pick issues or try to make things look worse than they really are. This too is unfortunately common human behavior when people aren't getting along. Sometimes having a manger involved in the process increases the likelihood of this happening; now appearances matter. So if an engineer thinks another engineer is doing a bad job, he or she has the strong inclination to make them appear that way in code review in front of management.

Ultimately the end result of engineering is what matters most. The details of getting there sometimes can be ugly. A good engineer should want lots of defects to be found in review. This means they are caught before end users can encounter them. It is hard to keep this focus when you are being watched and evaluated. Sometimes the best engineers make the most mistakes because they work on the hardest and trickiest part of the project. So having management there keeping an eye on things can give the exact wrong impression of the quality of engineering being performed.

Moving Along After Quick Approvals

Ensuring that review feedback comes back from all reviewers is usually a challenge. There is always a lot going on in a project and the last thing someone needs is more work of looking over someone else's tasks. For code reviews to be successful they have to work around people's busy days.

What happens is that the people who look over the code with the least amount of detail and care are also the most responsive to getting their reviews in. In software-driven reviews, this results in a quick "accept" and in meeting reviews this results in the reviewer claiming to be ready but having no real understanding of the code. It is easy to just give up and go ahead with a code review with the few people who have said they looked over it. This turns code reviews into rubber stamps. The slow people are the most valuable to code reviews — wait for them.

This makes things difficult. If reviews wait on people who are slow to come up with feedback, things may never move. I don't think there is any simple solution to this. Sometimes this can be caused by procrastination. But what is worse than procrastination is not taking reviews seriously.

An effective review has everyone who is most suited for finding bugs in the type of code being reviewed present and having spent time in looking for them. Don't give up on this goal even though sometimes allowances have to be made. Don't let code reviews switch to having the least attentive people rubber stamp it. There is little point in these kinds of code reviews.

Omitting Omissions

The usual way to to review code is to compare the new version to the old one in version control. Most tools have a way to pull up a difference showing the lines that were added, removed and changed. Some of the best ones allow for tagging lines with comments to track issues exactly where the are in the code. This usually works great but the routine makes it easy to forget to look for omissions.

A diff viewer only shows you what changed &mdash not what should have changed. I don't know of any good way to determine what should have changed beyond experience with the code or just general software engineering experience. So there is no way to prescribe a fix for this common problem. The best I can say is to look out for it. Try to get into the mindset when reviewing code to look around at unchanged code and try to think about what could be missing.

I've seen plenty of bugs in testing or production due to simple errors of omission. These are things that went through code review, weren't too complicated or involved to find, but were simply missed because they don't show up in a version control compare. Watch out!

Coding Standard Reviews

Different organizations can have different opinions regarding the value of having coding standards. If a project has a coding standard, there needs to be automated tools for checking it. It is a waste of code review time trying to find things that violates the coding standard. These kinds of inconsequential issues distract from finding real problems. In situations where automated standard checking tools aren't available, don't address coding standard problems beyond a single line item that standards compliance needs to be addressed. Log that and move on. Don't waste people's time in trying to compare coding styles against a coding standard. It is a distraction and makes code reviews slow and dreaded.

Including Optional Reviewers

I think there is plenty of room to be flexible on this, but it is good to try to avoid having optional reviewers. One potential benefit of code review is to help other people get up to speed with the code and learn about a project that they haven't been involved in. This means it is tempting to include anyone who may benefit from learning the system. This too can distract from having an effective code review.

One challenge to code reviews is ensuring the reviewers have looked over the code as in-depth as is reasonable. As soon as other people are included in the meeting that are there for other purposes, things can go down the slippery slope where rigor becomes optional. Having people involved that don't know the system can also slow down the process by asking obvious questions that could be dealt with in a one-on-one discussion rather than with the whole team.

Getting Off Track

The overriding theme here is that code reviews are important and anything that distracts from finding defects should be minimized and avoided. It is possible to be too strict and take things too far, but usually the opposite is the problem. It takes care and discipline to have an effective review but the results can make the difference between a failed product and something solid and stable for years to come.

The original Timex Datalink watches used a small IR sensor on the front that would read serial data sent to it from a computer. The computer would flash a bunch of white lines on your CRT monitor with a specific timing rate while you held the watch up to the screen. This took advantage of the CRT refresh timings with some clever programming. It was fun to watch the white bars go across and hear the beeps of the watch reporting that it got the data. There is even a patent with drawings on how this works: https://www.google.com/patents/US5652602

Datalink Patent Drawing

The original Datalink watches were limited in terms of I/O. Things like Bluetooth or high-resolution displays weren't possible at the time. This meant that the things to experiment with were mostly limited to setting alarms and adding appointments. Despite this, it was awesome and completely worth it!

In some sense the Datalink was the first smart-watch but it totally depends on your definition of smart-watch. The CRT monitor programming trick was a real wireless link even though it required line-of-sight and was single-directional. The Timex / Microsoft (yeah Microsoft was involved) software provided a simple GUI for inputting your watch data.

Timex later released a Datalink watch that had a USB connection. This allows two-way communication. So if you change something in your watch, it can sync back to the computer. It also had software that would allow for Microsoft Outlook synchronization. Having a USB connection was much nicer but there is still something awesome about reading lines flashing on the monitor.

My Collection

Lately, I've dug up my own Datalink watches and gotten the urge to get them back running again. Sadly, my original 150 watch has problems with it that I haven't been able to repair yet. The LCD zebra strips either have a fault or the connection pads aren't making good contact. This means some segments of the display don't work. I also happened to bend the back of the watch-case which damaged the peizo element when trying to open and close the watch. I must have opened and closed it too much and too hastily while working on repairing the LCD.

My original USB Datalink is in fine shape and I bought several other Datalink watches off of ebay to make up for my broken 150. Here is what my current collection looks like.

My Datalink collection. The order of the watch models from left-to-right are: 70, Ironman, 150, 150s, Ironman USB.

Running MCU Code

I haven't done much with programming the MCU on the watches. Some clever programmers did some work to reverse-engineer the original Datalink watches but Timex was nice enough to release a SDK for the Ironman USB (https://assets.timex.com/developer/datalink/). There aren't a lot of good use-cases for writing code for these watches due to the limited MCU and LCD. It still could be fun to tinker with.

Serial Programming

Because CRT monitors aren't common anymore and it depended on some really old software, it is quite a challenge to have a good system to program the Datalink watches. Timex had a laptop adapter they made in order to program the watches on a laptop that had an LCD screen. The adapter has a serial port connector along with a LED that blinks with the same timing that the CRT would. These adapters are in high demand and often go for a large amount of money on ebay.

While it would be possible for me to reverse engineer the CRT programming timing for the Datalink and try to reproduce it, it is much easier to go off of the work of others. The difficulty there is many of the early Datalink interest web pages don't exist anymore. Thanks to the Internet Archive I was able to find code that someone wrote that talks to the watch via a LED attached to a serial port. I got this partially working but it was pretty flaky and would often result in programming errors.

After a desperate attempt at scouring the web for a solution, I finally found something that didn't require me to do significant work from scratch. There is a very nice github repo of https://github.com/dfries/datalink_ironman that not only includes a Linux application for talking to the serial port for programming the watch but also a MCU application for running on the Teensy (https://www.pjrc.com/teensy/) board. Unlike the serial port to LED connection, this has run really solid for me. It is a near-perfect programming solution.

Running the datalink_ironman code on a Teensy is quite a bit cheaper than trying to acquire a Timex official laptop adapter off of ebay. Also because it works with a Linux command-line application instead of the Windows 3.1 GUI application is is much more useful and versatile too.

Teensy Datalink programming cable. Not as fun as a CRT but it works!

More Restoration

I'm not sure yet how much more I will do with my Datalink project. Some of the watches I got off of ebay came in pretty bad shape. I've replaced the wrist straps of all of them. I tried to match the original wrist straps as much as possible but that is really hard to find. The 150 / 150s has a nice glass lens but most of the watches are plastic lenses. I've been successful at polishing the scratches out of the plastic though and have a nice shine.

I haven't decided if I am going to try to attempt a paint restoration on the watches that has had paint has worn off. It is pretty impossible for me to match the existing color but I might be able to find something close. There is always the risk I will end up with a paint job that I am unhappy with and am unsure what to do.

I still have a chance to resurrect my old 150 watch. This has nostalgia and emotional appeal to me but has been quite frustrating so far. The zebra strips for the LED are flaky but I might be able to find a way to get contact with some really delicate work. It should be possible to bend the watch back into mostly the original shape but the piezo element is completely damaged. I haven't yet figured out if I can re-use a piezo disc element and find a way to mount it on the back of the watch cover.

Not only are the old Datalink watches cool from a nostalgia perspective, they are just generally interesting technology. They also easily outmatch today's smartphones as they can run for years on the same 3-volt battery. They don't deserve to be lost to history. Maybe someday something similar will be made again.

Other Languages

The idea of conditional operator is not unique to C and is common in functional programming languages. Some of the dislike for the conditional operator stems from preferring statement-based programs over expression ones. So the "if" statement feels just right and simple to someone thinking step-by-step when writing a procedural program. However, a conditional operator feels right at home to someone writing in a functional language. This is actually a good argument to avoid it in C code. C programmers don't generally write code doing a lot of complex work in expressions.

It is important to realize that dislike for this operator is a stylistic and background preference and not something inherently bad about its use. In this post, I provide an example of the use of the ternary operator that I think should both be comfortable to procedural programs as well as fitting an important need that other C constructs don't handle well.

Lisp

In Lisp, the equivalent of the conditional operator is the "if construct" (if (exp) (true_action) (false_action)). Lisp isn't a pure functional language so this is often used in the same way the C "if statement" is. The major difference is that this is actually an expression so the true and false condition values are what the expression is evaluated to. This means it can be assigned to variables or passed to functions exactly the same way the C conditional operator can. So while it is named "if", it has way more in common with the conditional operator than a C "if" statement.

F#

F# continues the trend of having "if" be an expression.

if exp then true_value  
else false_value

Like lisp this is often used like an "if" statement is, however it has a value and can be used like any other value or expression.

Bad Usage Patterns

C expressions can be quite powerful and contain things that can be confusing and unexpected. People learning C for the first time all run into the "=" being an expression. This means you can have code like if (a = 1) be completely valid but totally the wrong. Also, the ability for integers and pointers to be treated as boolean can cause for confusing expressions. This allows for some nice terse usage patterns but runs the risk of getting too clever and being confusing. Of course operator precedence is also a common trap. When combined with these other behaviors of C expressions, conditional operators can be used to make them even harder to understand.

When trying to fix non-working code, it is easy to just slip in a conditional operator to try to fix it in as few changes as possible.

int count = strlen(a);

Later on becomes

int count = a ? strlen(a) : 0;

Which later on becomes

int count = a ? (strcmp(a, "undefined") ? strlen(a) : -1) : 0;

It isn't hard to see how this can quickly slip in everywhere in the code making things a mess. Keep in mind, this is just bad usage of the ternary operator. Anything can be abused and it isn't intrinsically bad. As mentioned above, it is often used in other programming languages without issues.

Let's Do This Right!

Ok so how do we use the conditional operator in a way that isn't confusing and fits in well with C-derived languages? The conditional operator can help with some usage patterns where other language features don't work as well or have limitations. I'm going to present an example of how this operator can be used as a better alternative to a switch statement.

Switch / Case

The switch statement is one of the odder programming language constructs in C. Being able to map one value to another one or to an action is a common need. But the switch suffers from odd syntax, needs lots of "break" statements and is a little tricky and error-prone.

Here is a simple example of a switch statement

int result;
switch (val) 
{  
   case 0 :
     result = 5;
     break;
   case 1 :
     result = 20;
     break;
   case 2 :
     result = 100;
     break;
}

This has a myriad of issues:

• It is verbose; the extra "break" statements, the curly braces all make a simple numeric mapping large.
• It is easy to miss a "break" statement. This is such a common mistake that C# goes to far as to require a "break" statement or the code won't compile.
• The type of variable you switch on must be integral or an enum. This rules out doing string comparisons or comparing on other common data types. This is very constraining when coming from other programming languages that don't have these limitations.
• The values you compare with case must be constants.
• In this example, it isn't possible to make the "result" variable const. Not everyone values using "const" as much as I do, but for those of us who do, this is a big deal.
• There are no compiler checks that "result" has been defined by one of the case blocks. Omitting the default block is fully allowed. It is also possible to have the case blocks forget to assign a value to "result".

So here is a nice alternative

const int result = val == 0 ? 5 :
                   val == 1 ? 20 :
                   val == 2 ? 100 :
                   (assert(false), 0);

• This code is much smaller than the switch statement
• The formatting clearly shows it is a mapping from the left to the right value. One can view it as 0 => 5, 1 => 20, 2 => 100 and it isn't too far off from the actual code syntax.
• The code can use const if desired (yes please!)
• You will get a compile-time error if you don't specify a default value.
• This pattern works with types other than integers and works with comparisons other than simple value equality.

The formatting of this code is critical. Without the spacing and alignment this can be formatted to look confusing. I have also seen people format something similar except with the ":" on the start of the following line rather than at the end of the current line. This is just as clear but I, personally, prefer it on the end of the same line.

I can understand objections to the use of the comma operator with the assert. It is a bit of a trade-off. For those who don't know, the assert will be evaluated and the "result" expression will get the value of 0. This is just my little touch and isn't required. It is possible to simply have a valid default value. Another nice option (in C++) is to call a templated function that throws an exception. The template is needed to be able to write one function to match any expression type. Just keep in mind that the comma trick isn't required and shouldn't be an objection to the overall pattern; I wanted to show how flexible it can be.

One downside of this pattern compared to the switch statement is usually compilers can use a jump table to optimize the switch statement. This is why the switch only supports integers. In theory, a compiler could use one here as well, but it is a harder optimization to make. So this is a case where performance could be slightly impacted in exchange for code clarity.

Unlike switch statements, this doesn't have the ability to fall through the case blocks. I don't think this is usually a problem. As noted, the C# language requires "break" statements as fall-through isn't supported. It isn't something that I usually miss but am noting it as it is something switch has the upper-hand on — when done intentionally at least.

Conclusion

While not perfect, I think the example I show is a good use of the conditional operator. It is clear, flexible, and reasonably simple. I don't remember where I have seen code similar to this before but there aren't a lot of examples of it online. I think this is a great use of the conditional operator and encourage it to be used instead of switch statements or "if" chains where it makes sense. Even for the unconvinced, hopefully this at least showed some merit for this technique and that conditional operators don't have to be contributing to confusing code.