idmillington / cyclone-physics

The Physics engine that accompanies the book "Game Physics Engine Design"
MIT License
931 stars 262 forks source link

Unclear variable names in contactPoint(...) in collide_fine.cpp #50

Closed e2-dunstan closed 4 years ago

e2-dunstan commented 4 years ago

https://github.com/idmillington/cyclone-physics/blob/master/src/collide_fine.cpp

Vector3 toSt, cOne, cTwo; real dpStaOne, dpStaTwo, dpOneTwo, smOne, smTwo; real denom, mua, mub;

If someone could clear up what each of these variables represents it would be much appreciated. I wish to understand.

ButchDean commented 4 years ago

Variables have no context outside their use in statements or expressions. If you can't understand what the code is doing by reading it and running the examples, you may need to reread the chapter then run and examine the code again.

e2-dunstan commented 4 years ago

Variables have no context outside their use in statements or expressions. If you can't understand what the code is doing by reading it and running the examples, you may need to reread the chapter then run and examine the code again.

This code is not featured in the book, or at least I cannot find it. I am working through the book and understand the theory however those variable names are very obscure. I have added this issue just so those names can be clarified to me, they do not need to be changed. (PS: I know what a variable is...)

ButchDean commented 4 years ago

Honestly, I'm not saying that you don't know what a variable is, I'm trying to point out how you discover what it is intended for just by looking at the code. As an example, you asked what the variable 'toSt' is. For me, just by looking at its context within contactPoint(), the code at line 370 suggests that it is used to retain the difference between two points in 3D space, and that is all you really need to know. Elaboration is given in the following lines where deltas between the first and second points with that point are calculated.

That is what I mean by looking at the context over relying on names to describe what the code is doing - could the vars be named better? Sure, but they aren't. If you want then renamed you can perform a basic refactoring exercise to rename them as you see fit, but this is not something that needs fixing in the published code or for someone to take the time reminding themselves of what everything is doing in order to provide an explanation.

When you become a full-time programmer you will see what I man. Good luck! :)

e2-dunstan commented 4 years ago

Update: I have now figured out what all the variable names represent - duh! For anyone else with a slow brain like me: