3 ms·
Hear, hear. I won't say this is the best advice in all circumstances but we settled for roughly the same principles and in the end it just works out. In case 1
by stinos 9y ago
Hear, hear. I won't say this is the best advice in all circumstances but we settled for roughly the same principles and in the end it just works out.
In case 1 we usually use asserts though (which are always on), but that's more of a preference because it states intent (asserts are just used to guard against insane programmer behaviour, and they are used judiciously, to the point we will refuse large patches which do not introduce any asserts) and makes debugging easy (since they have the debugger break). As a result, code became less buggy. Programmers don't want to trigger asserts because they are 'crashes' and being the cause of one is usually the thing you don't want to be. As such, people become more aware of every single line of code written, every input provided, ... . Yeah there might be other ways to reach that effect, but using assert all over the place did the job just fine.
- ensiferum 9y agoYep, I also have my own assert macro that when violated terminates the process with a core dump unless running in a debugger when it triggers a break point. Works out fantastic.