Follow up to Pay Rate Calculator
Well, you have started to use decimal instead of float and introduced a couple of named constants but pretty much every other point I stated in my answer to the other question still stands.


Naming conventions (PascalCase for properties)
You now have introduced a WithholdingRate property but that doesn't affect anything (the property is not used anywhere in the class)
Although you have introduced a named constant _PayRateDefault you are still using magic numbers in various places.
You have added some rules but they are implemented inconsistently - in hours you enforce the rule in the get while in payrate you do it in the set.
The way you have added the rules is simply bad - you silently coerce the values and the user of your class won't have a clue what's going on. 

Assume this calculator is used to process the payroll in a company with lots of employees. Further assume that some of those are contractors which have not worked in the last week for whatever reason. Now you read in the work hours for each employee and everyone who hasn't worked at all (hours == 0) will get a full week payed - ouch.

If properties have restrictions on what range of values they should be in then enforce them in the set method by throwing an ArgumentException stating what was violated. It's better for your program to crash with an exception than to spit out bad data.

One of the few places where coercion of values makes sense is in user controls which force out of range values back into the range and then feed that back to the user (e.g. numeric up/down controls which a given min and max) but in most other cases it will do more harm than good.


Unfortunately your code has become somewhat more convoluted than the original.