I can't build EM and so was poking through the code.

- EM{noise, resample, etc} should be just be {noise, resample, etc} to be consistent with other names in other modules and the core (all access are already prefixed with via the paths and namespaces).
Only the files have that name. Functions don't have the prefix.

- in general it is less error prone to use an enum for modes rather than a string (in noise, for example) as they get documented better and can only exist in correct values
 

- calling the arguments to add_noise op1 and op2 is horrible. They should have descriptive names.
add_noise uses different functions with different meanings for op1 and op2, thus they can't be described properly. They are 2 arguments.

- given we have a rotation class, "project" should use that rather than its own convention for defining rotations
project is a hard function to develop, and the math behind it is far better implemented with a given convention. Hence the definition.

- in general we avoid passing return return values as arguments ("project"). At the very least, if you do that you need to make sure that the non-return arguments are const refs, rather than refs and the last arguments.
reasonable

_______________________________________________
IMP-dev mailing list
IMP-dev@salilab.org
https://salilab.org/mailman/listinfo/imp-dev