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.
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.