4 ms·
This leads to brittle code - it's easy to determine if is_player_untouched state changes between those two conditions when writing the code but when someone els
by rubber_duck 10y ago
This leads to brittle code - it's easy to determine if is_player_untouched state changes between those two conditions when writing the code but when someone else edits that code it's also easy to introduce something that will break it and the monolithic/big function makes it hard to keep track of assumptions like this and it leads to a lot of code changes in those big functions as well. Even worse this kinds of bugs usually end up being hard to test if you're not covered with unit tests, and games rarely are, and big functions go against testing practices.
- bluetomcat 10y agoIt sure leads to brittle code if assumptions and contracts in the code are not crystal clear, but Carmack's point in this particular article was about writing "consistently performing" code which doesn't degrade under specific conditions. In my refactored example, you wouldn't be eventually calling `is_player_untouched()` once more if `some_other_condition` is true.