3 ms·

Sometimes you have to work with a third-party system or interface that is sending your application dirty data, and you need to account for it in your code in cr

Sometimes you have to work with a third-party system or interface that is sending your application dirty data, and you need to account for it in your code in creative ways that may not be obvious to someone who is just reading it. For example in our current project w'ere working on a front-end piece that connects to a CRM application where no rules or constraints have been set up or enforced for a long time. We're talking stuff like zip code fields having values like "I don't know" or "XXXXX". So for every function that receives such values from a lookup, we have to clearly document those edge-cases in the comments and explain how the function deals with them.

joshka 11y ago
ZipCode GetZipCode() { var result = _crm.GetZip(); return isValidZip(result) ? new ValidZip(result) : new InvalidZip(result); } class ValidZipCode : ZipCode { ... } class InvalidZipCode : ZipCode { ... } No edge cases, perfectly 'documented'.
- codingdave 11y ago
  How do you consider that to be documented? Why do you return a different class for invalid zips? Is it OK to use invalid zips in all cases? If not, why not throw an error? If so, what benefit does the separate class give you? Because that code doesn't handle bad data - something in the objects or some other function must handle it, and this code doesn't really tell us what is going to happen with a bad zip. It just tells us that the code noticed it. This is exactly why comments can help.
  - joshka 11y ago
    See the null object pattern. Encapsulate all such behavior you've mentioned with appropriate OO patterns, and stop writing procedural code spread all over the place that has to rely on comments to inform you about the right way to handle the bad data. Handle the bad data cases simply and specifically. Feel free to add some code that explains your use case and where you think such comments are required...

joshka 11y ago

ZipCode GetZipCode() { var result = _crm.GetZip(); return isValidZip(result) ? new ValidZip(result) : new InvalidZip(result); } class ValidZipCode : ZipCode { ... } class InvalidZipCode : ZipCode { ... } No edge cases, perfectly 'documented'.

codingdave 11y ago
How do you consider that to be documented? Why do you return a different class for invalid zips? Is it OK to use invalid zips in all cases? If not, why not throw an error? If so, what benefit does the separate class give you? Because that code doesn't handle bad data - something in the objects or some other function must handle it, and this code doesn't really tell us what is going to happen with a bad zip. It just tells us that the code noticed it. This is exactly why comments can help.
- joshka 11y ago
  See the null object pattern. Encapsulate all such behavior you've mentioned with appropriate OO patterns, and stop writing procedural code spread all over the place that has to rely on comments to inform you about the right way to handle the bad data. Handle the bad data cases simply and specifically. Feel free to add some code that explains your use case and where you think such comments are required...