Open seyhunsaral opened 4 years ago
Good idea! I would like to keep it that way.
There are still a lot of function or variable names that appear to be rather inefficient, for example: get_transformed_mallows_normalization_constant, dispersion_parameter, number_of_alternatives, ...
What do you think of changing things like "constant" -> "const", "parameter" -> "param", "number" -> "num", ...?
What do you think of changing things like "constant" -> "const", "parameter" -> "param", "number" -> "num", ...?
All sounds good. I am still not sure about generate
though. Is it really crystal clear for everyone that it is generate. For instance alternatively, we can use generate
only for voter generation. Then we don't need to use generate_mallows_voters
but just generate_mallows
.
Maybe we can meet at a certain point and go through the code once and make a huge refactoring attempt. Since the package is alpha and probably no one is using it yet, we have the luxury to change things.
Should we create a section for naming conventions on CONTRIBUTING.md
? We can take a look at some principles we can use. For instance "The Art of Readable Code" by Boswell and Foucher suggest (among other things):
download
instead of get
)tmp
)CanListenOnPort()
instead of ServerCanStart
)What do you think?
I somehow like the fact that having "voters" in the function name directly shows that this function is about voters and not candidates or something else (might be important for people who do not know Mallows model), but probably this effect can be achieved in some other way... What is the reason you rather want to keep generate?
Talking about this and creating this section about naming conventions in CONTRIBUTING.md
sounds good.
@annikahe I was fitting the style to
pep8
and we had many long lines I had to break. (although I really don't like how they look). So just to alleviate it a little bit, I changed allgenerate
functions togen
. should we keep it that way or do you think have the value of having a verb in functions?