Shibboleth backatcha. First, the problem was "Customer 1" and "Customer 2" not "dozens" nor thousands.
Second, the question was whether total price included tax on the gross amount or tax on the cost amount, which *might* vary by state or locality, not dozens of variations. I also think the "do the simplest" rule would say: when you first run into the situation, write and IF statement. When there are three cases, update to a CASE. When there are too many to handle easily, promote it to a Strategy Pattern. Solve the problem in front of you. YAGNI: You Ain't Gonna Need It. Depending on the exact application and the customers involved, it's also possible that individual items may be taxed at different rates (materials v. services v. labor) or that the entire order might be tax-exempt for other reasons. And what is taxed and in which amounts may vary by municipality, county, state and country. All of these are common problems. There are standard "Acceptable Accounting Practices" of calculating these, and ideally the code ought to be easily accessible and readable and kept in source code control (another reason to keep them out of memo fields!) so MB can explain exactly what is done when he is subpoenaed by the taxing authorities, or when the customer discovers at the end of the year that they have not calculated their withholdings correctly. On Tue, Nov 17, 2015 at 11:16 PM, Ken Dibble <[email protected]> wrote: > >> Stuffing executable code in a memo field is an unholy hack. It's a >> PITA to parse, debug, or cross-reference. Compilers don't catch simple >> syntax errors, error-handlers can't tell you the line of code, >> cross-reference won't flag the use of the variables. >> >> If you've got an object oriented system, you use a strategy pattern. >> >> If it's PRG based, you use a switch: >> >> If Customer.PricingStrategy = 1 >> DO Strategy1 >> ELSE >> DO Strategy2 >> ENDIF > > > Well, I think the idea was to avoid having to code, compile, and distribute > a software update every time you need to introduce a new customer and/or a > new variation on the formula. > > If you don't like memo fields, it could be done using single rows in a table > closer to the design that Joel suggested. The VFP designers themselves used > memo fields that violate various rules of data normality to create some of > their tools. It seems to work just fine. VFP's string parsing is ultra fast. > > I think the part about syntax errors and the compiler is a shibboleth. These > are simple formulas, they follow a simple pattern. Only the formulas would > be stored to the table. The code to parse them would be compiled and tested. > And if you had an issue with whether or not a particular new formula might > work with the code, a simple testing routine could be built into the form > that is used to store them to the table, so you could debug them before you > store them. > > I've always been told that dozens of CASE options or bazillions of IF ELSE > structures is "inelegant" and difficult to maintain. "Do the simplest thing > that could possibly work." What's the simplest way to accommodate an unknown > and unpredictable number of customers who will want to choose between a > relatively small, but not fully known, number of formula options? Put 'em in > a table. > > Granted this might become too cumbersome if the universe of formula patterns > gets a lot larger, but that's not the problem that was presented. > > Ken Dibble > www.stic-cil.org > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CACW6n4t=rrn5k4hofycefzqzy7voc3k8tvyp0gqqjbmtvhs...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
