search

pele-python / mcpele

Monte Carlo and parallel tempering routines built on the pele foundation
Other
20 stars 5 forks source link

const and typedef where doable #13

Closed kjs73 closed 10 years ago

kjs73 commented 10 years ago

The following is not about formatting, but almost.

What do you guys think about having as much as possible?:

  1. const
  2. typedef

These are very minor things, but in my opinion: Point 1 reduces the error potential. Point 2 makes the code more flexible, shorter, and more readable.

On the other hand, I see that both things could be a disadvantage for Python wrapping. Maybe this would make the wrapping more complicated or unclear.

js850 commented 10 years ago

Here's my two cents:

We should use const wherever possible. It makes intent much clearer if nothing else.

I'm less thrilled about typedefs. They do increase flexibility, but I'm not sure that we would really take much advantage of it. Do we really ever want to fully support Array? Probably not. And I think they often decrease readability. But they are definitely a good idea in some cases. e.g. for the vector of pointers to Actions. It really doesn't matter if it's a vector or list or map, and using typedef for that can make it easier to change later.

kjs73 commented 10 years ago

OK, I see your point on the flexibility! Also, with the "auto" type deduction the readability / shortness aspect will probably become less important.

kjs73 commented 10 years ago

PS: In terms of convention, what do you think about not having "using" in header files, only in ".cpp" files? The advantage is that then there can be no conflicts with the naming by including different headers. Otherwise, we are fixing the "using"s of the header for each file that includes them.

js850 commented 10 years ago

what do you think about not having "using" in header files, only in ".cpp" files?

Yes, this is good practice. We should change it where we see it.

smcantab commented 10 years ago

Hi guys,

I agree with Jake, const is good, typedef less good.

Regarding array...I think we should consider transitioning mcpele to use a more complete array structure, like the one provided by the eigen library. I have not done enough research to say whether eigen is the best around but I think that mcpele should be structured so that the user can do manipulation of array as efficiently as possible but also as easily and clearly as possible (numpy style in other words). For example, one might want to do some simple linear algebra manipulation of the arrays without going back to python.

I shall start working on this as soon as we get the more urgent stuff sorted.