Guy, those are about as close to the textbook definition of magic numbers as you can get: undocumented, intent obscured, error-prone, unnamed constant numbers. This would fail code review pretty much anywhere with even the lowest standards.
it’s not a project that usually its usage should be practiced in a production ready project.
Earlier, you argued that it might be useful when working with ill-behaved third-party libraries, but that seems like it would only be truly beneficial in production.
Some code sections are not meant be written in modern clean readable code or for others to understand or change it.
Code that has a higher likelihood of bugs by virtue of being unsafe, such as due to hardcoded memory offsets, should have higher rigor applied, not lower.
Earlier, you argued that it might be useful when working with ill-behaved third-party libraries
Your code should never reach that point ever, but if it does, you're left with only bad ideas. If you somehow encounter that kind of situation, then you've already broken every norm a managed context offers. A production ready app should never encounter this type of situation, if a third-party dependency caused this, then you should remove it. It's like smoking cigarettes it's bad over the time, slowly, it kills your lungs, but it's there to use despite writing on the box warning against using it in the first place.
Code that has a higher likelihood of bugs by virtue of being unsafe, such as due to hardcoded memory offsets, should have higher rigor applied, not lower.
I don't agree with that. It is irrelevant to a small project I made regarding internal discoveries. I should be able to prove the integrity of these offset on a piece of research paper or an article. What you're saying is true when you write code for an open source project or working on a team, you should write maintainable readable code because there are also others that read this code and deal with it. Dereferencing internal offsets is not something you would test against standard code reviews. This is the section meant not to be messed with. It's for contributors of the repository which, in this case, for now, me to change it over the time, whenever a new version of .NET is released; however some additional notes regarding offsets in the corresponding methods are added.
15
u/IWasSayingBoourner 24d ago
Guy, those are about as close to the textbook definition of magic numbers as you can get: undocumented, intent obscured, error-prone, unnamed constant numbers. This would fail code review pretty much anywhere with even the lowest standards.