cyclicGroupOfDegree3 is a terrible name, unless you need to be really specific about degrees. cyclicGroup, please. (and I could imagine: cyclicGroup.degree() == 3)
dP is also a terrible name. My first thought goes to derivatives. directProduct is the right name. dProduct, dProd (if you like the Numerical Recipes style, expounded below) are better than dP, but still wrong for a library.
So first, let's assume directProduct is a library somewhere; maybe one you've even created. So let's reconstruct:
val z = directProduct(cg1, cg2)
Better, and more believable. And if the declarations of cg1 and cg2 are obvious (ie, the lines directly preceding) then you might have a case. I imagine directProduct(group1, group2) would actually be a happy medium. And if you use z in the next line or two, I'd let that slide.
The thing about Numerical Recipes is that often you're taking math syntax and coding it. Often doing so requires a good deal of commenting and temporary variables. One thing the book gets very wrong is it's function declarations (the function body is a separate argument) -- at the very least, rooted in a past of 80-character-lines and before code reviews. The first example in the book:
void flmoon(int n, int nph, long* jd, float* frac)
ought, in a modern era, be something like:
void MoonPhaseToDay(int n_cycles, int phase, long* julian_day, float* fractional_day);
If for no other reason than I can have some hope at understanding the second argument, or finding it again. You'll also notice flmoon is a misnomer -- it computes more than full moons!
cyclicGroupOfDegree3 is a terrible name, unless you need to be really specific about degrees. cyclicGroup, please. (and I could imagine: cyclicGroup.degree() == 3)
dP is also a terrible name. My first thought goes to derivatives. directProduct is the right name. dProduct, dProd (if you like the Numerical Recipes style, expounded below) are better than dP, but still wrong for a library.
So first, let's assume directProduct is a library somewhere; maybe one you've even created. So let's reconstruct:
val z = directProduct(cg1, cg2)
Better, and more believable. And if the declarations of cg1 and cg2 are obvious (ie, the lines directly preceding) then you might have a case. I imagine directProduct(group1, group2) would actually be a happy medium. And if you use z in the next line or two, I'd let that slide.
The thing about Numerical Recipes is that often you're taking math syntax and coding it. Often doing so requires a good deal of commenting and temporary variables. One thing the book gets very wrong is it's function declarations (the function body is a separate argument) -- at the very least, rooted in a past of 80-character-lines and before code reviews. The first example in the book:
void flmoon(int n, int nph, long* jd, float* frac)
ought, in a modern era, be something like:
void MoonPhaseToDay(int n_cycles, int phase, long* julian_day, float* fractional_day);
If for no other reason than I can have some hope at understanding the second argument, or finding it again. You'll also notice flmoon is a misnomer -- it computes more than full moons!