Since the health is a float, yeah, it can create issues. A health of 0.000000001 is greater than zero, but that would almost assuredly be displayed to the user as simply 0, causing player confusion. The easiest solution is to have health and damage always be integers. A less great solution is to use a non-floating point decimal format. If such doesn’t exist in your language, you can emulate one by having health and damage both always be integers, but move the decimal point over, say two points, when displaying to the user.
It sounds like the only concern you have with code is its bugginess, which is short sights. This is unfortunately better documented code than stuff I’ve seen in production. Obviously no one should do this, but let’s not act like there’s no benefit
Indeed, you can achieve a better result with less verbose naming convention. And choose better variable name to make it obvious than 0 Hp is death. While i don’t like having too verbose variable name (as it impacts the readability and quick understanding of the function), i’m not against that for the function name… without going too far of course!
Best is too have proper datamodeling of the object manipulated on top of some classic basic comments. Good interface contract is also a minimum. Best is to have full datamodeling of all the services, objects, in and out interactions between them, etc.
Documentation is a mandatory piece of the code delivery (with tests being the other important part) far too much forgotten if you don’t enforce it on your teams.
I don’t see the benefit of this long naming convention…
It still allow bug to exist… like the fact that, with this code, the player can still play with 0 Hp.
Should have been better to put a “if(health <= 0)” instead of “< 0”
I asked this question on this post on a different instance, but would there be issues being that the code compares a float to integer zero “0”?
Since the health is a float, yeah, it can create issues. A health of 0.000000001 is greater than zero, but that would almost assuredly be displayed to the user as simply 0, causing player confusion. The easiest solution is to have health and damage always be integers. A less great solution is to use a non-floating point decimal format. If such doesn’t exist in your language, you can emulate one by having health and damage both always be integers, but move the decimal point over, say two points, when displaying to the user.
It sounds like the only concern you have with code is its bugginess, which is short sights. This is unfortunately better documented code than stuff I’ve seen in production. Obviously no one should do this, but let’s not act like there’s no benefit
Indeed, you can achieve a better result with less verbose naming convention. And choose better variable name to make it obvious than 0 Hp is death. While i don’t like having too verbose variable name (as it impacts the readability and quick understanding of the function), i’m not against that for the function name… without going too far of course!
Best is too have proper datamodeling of the object manipulated on top of some classic basic comments. Good interface contract is also a minimum. Best is to have full datamodeling of all the services, objects, in and out interactions between them, etc.
Documentation is a mandatory piece of the code delivery (with tests being the other important part) far too much forgotten if you don’t enforce it on your teams.
Came scrolling for this ^^