// This is ambiguous, lazy, and the worst form of mutation.// Its a terrible way to program in any language!// Its what was done in "c" 40 years ago// 93 charactersletd=b*b;d-=4*a*c;if(d<0)return[];d=Math.sqrt(d);// A better way to program.// Totally non-ambiguous, non lazy, self commenting. // No concern for mutability here.// 193 characterslettaxmultiplier=taxbase*taxbase;letexciseTax=4;letfiguretax=taxmultiplier-(exciseTax*stateTax*countytax);if(figuretax<0)return[];lettaxRoot=Math.sqrt(taxMultipier);// even better, we have a tax rule a object which, for safety must be immutable; // unless the new taxable rates arrive of which we handle separately somewhere// 138 charactersleta={taxbase:.04,taxmultipler:'*2',stateTax:.1,countyTax:.05}returna.taxmultiplier-(a.exciseTax*a.stateTax*a.countytax);// This allows us to pass in an object and return a number based on object content.// 66 charactersfunctioncalcTax(a){returna.taxmultiplier-(a.exciseTax*a.stateTax*a.countytax);}// implementing a decorator// 72 charsfunctioncalcFloodTax(a){letfloodtax=.005;lettax=calcTax(a);returntax*floodtax;}// a decorator with injected floodtax// Total characters 32functioncalcFloodTax(a,floodtax){returncalcTax(a)*floodtax;}
If a programmer can type 200 words per minute or 4 lines of code. From a time perspective it's just better to be a better programmer.
My main point is if the programming is done correctly we should be able to mutate any time we want. It's just way easier to set a field to a new value than to do the immutable tricks.
I was struggling to find a small example that could get my point across. Usually confusion due to mutable states arise in larger systems with many pieces, in my experience.
And yes, I agree your example is better code and more readable. But your code uses immutability to improve readability, so how does that support the idea that mutability doesn't decrease readability?
Good point, the code example was only trying to point out that we don't need to be forced into an immutability model all the time, rather with proper techniques we can mutate at will and not worry about problems down the road.
But thanks for pointing this out. I'm beginning to see that javascript programmers may not follow the techniques listed above, so the "immutability" rules are good. Immutability is a creedo, a warning about what happens when mutating objects by reference where not intended. Always a bad outcome.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The example shows poor programming technique.
If a programmer can type 200 words per minute or 4 lines of code. From a time perspective it's just better to be a better programmer.
My main point is if the programming is done correctly we should be able to mutate any time we want. It's just way easier to set a field to a new value than to do the immutable tricks.
I was struggling to find a small example that could get my point across. Usually confusion due to mutable states arise in larger systems with many pieces, in my experience.
And yes, I agree your example is better code and more readable. But your code uses immutability to improve readability, so how does that support the idea that mutability doesn't decrease readability?
Good point, the code example was only trying to point out that we don't need to be forced into an immutability model all the time, rather with proper techniques we can mutate at will and not worry about problems down the road.
But thanks for pointing this out. I'm beginning to see that javascript programmers may not follow the techniques listed above, so the "immutability" rules are good. Immutability is a creedo, a warning about what happens when mutating objects by reference where not intended. Always a bad outcome.