Sure, and I'd call that bad code unless it exists because there are far more considerations than sales tax. Either way I don't see how that is an example of when to or not to leave a comment.
>Sure, the functionality to find that SalesTax number might take tens of thousands of hours to create and cover a multitude of egde cases. Still with proper context, structure, naming conventions, etc the why’s should be clear.
Again, that's just not true. I have a hard time imaging that you're a professional engineer with real world experience if you've never found yourself in a situation where variable names alone could not express the _why_ behind a piece of code.
>Elegant code is elegant when it encapsulates the why’s not just the how’s
Great, not always possible. For example:
// We have a longer than normal backoff period on
// timeouts here because device XYZ is a piece of junk
// and randonly stops responding for minutes at a time
// version 2 of the spec switched to an XML format and
// allows the header to be anywhere above the root
// element of the document (as a processing
// instruction). We cannot define a reasonable min
// header position/length. Just read the whole file.
const size_t MinHeaderLength = std::numeric_limits<size_t>::max();
// Workaround issue caused by .NET 4.6.1 upgrade which
// has more restrictive certificate checks for secure
// connections. This is currently affecting SignalR
// Scaleout connections to Azure Service Bus.
AppContext.SetSwitch("Switch.System.IdentityModel.DisableMultipleDNSEntriesInSANCertificate", true);