| | 116 | |
| | 117 | == Nulls == |
| | 118 | Nulls make code much more complicated by introducing special cases that require special null-checking logic in every client. They often and easily cause hard-to-diagnose errors. |
| | 119 | |
| | 120 | * Avoid returning nulls wherever possible. Unfortunately the design of python and web2py make this very difficult. E.g. if creating a data structure from many objects, instead of returning nulls from each object and requiring special checking before adding to the structure, pass the data structure to the objects and let them fill in as necessary. |
| | 121 | * Check for nulls and handle them properly unless you are sure you aren't going to get them. |
| | 122 | * Unit tests should check that nulls aren't returned. |
| | 123 | * if you must return a None at the end of the function, do so explicitly, to make the intention clear, rather than falling off the end. |
| | 124 | * Database fields should generally be non-nullable. If there is the chance of unknown data in certain fields, it indicates that the table may be too big, and those fields may need splitting out into separate tables. It may seem reasonable to allow unknown data, but it places the burden of null-checking on every client of the table. If any client doesn't don't do it (the default), then there is a risk of undefined behaviour. By making them non-nullable, we get a level of code validation from the database layer. |
| | 125 | |
