Hi Richard,
Thanks for your feedback. I agree that we should try to get rid of constants.cc and unify the handling of constants in ARTS. I started some refactoring but ran into the problem of some of the tests related to lineshapes becoming instable. I am still in the process of tracking this down, but it will have to wait until later this week or after the ARTS week. Regards, Simon ________________________________ From: Richard Larsson <ric.lars...@gmail.com> Sent: Tuesday, August 27, 2019 10:48:49 AM To: Simon Pfreundschuh Cc: ARTS Development List Subject: Re: [arts-dev] Renaming of constants Hi Simon, I think that this is a good idea. I would go further and remove all of constants.cc while you are at it. Or as much as possible. Some notes: You have misunderstood one thing. The Delta_nu_Cs variable is a properly named snake_case variable that follows the naming convention of the International System of Units. The Greek letter Delta is used by them, the Greek letter nu is used them, and cesium in short is Cs, not cs. Of the variables in Constant, two are clearly not following the proper naming (though I might have missed others). NA should be N_A and k should be k_B to be consistent with SI standard notation in snake_case. If you wish to change to another case style, whatever else your do, please be consistent with capitalization in SI, so that (for example) DeltanuCs is both the Pascal and camel case of said variable. Please do not make up your own variable names while ignoring SI standards as this will just reduce the readability of the code. Your example of kDeltaNuCs is one example of making up a new variable name, since Nu is not used in the SI standard notation (and so it should not be in ARTS). The extra "k" at top is very very ugly and I think that it should not be there. Just use the namespace instead to separate these things. This is in the Google style anyways. Exceptions to this would be in the Conversion namespace, where a k at the top might be warranted (since the variables are not really meant to be used but instead the conversion formula should be used). I am unsure what Google believes about the use of static in the namespace code. This should perhaps be removed. The Conversion namespace is completely messed up in naming and can be changed as you please. If you are renaming these variables anyways, using Conversion::sind and the rest of the degree-based trigonometry whenever possible (i.e., in most of m_ppath and ppath) would be good since it makes the code easier to read (by making it shorter). With hope, //Richard On Tue, Aug 27, 2019, 08:03 Simon Pfreundschuh <simon.pfreundsc...@chalmers.se<mailto:simon.pfreundsc...@chalmers.se>> wrote: Dear all, We are currently in the process of establishing more explicit coding guidelines with the aim of improving consistency and ultimately the quality of the ARTS code base. To make our life easier, it has been decided that we try to adhere to the google C++ coding style, at least w.r.t. naming and formatting conventions. One problem that I encountered is that the naming of constants, at least those defined in constants.[h, cc], is not consistent. Currently some of the names are all caps (AVOGADROS_NUMB, why are you screaming at me?), others use mixed case (Delta_nu_Cs) and others only use small letters. In lack of a better idea, I would propose to change this to follow the google style guide. This would mean prefixing all constant names with a k followed by the variable name in camel case: kAvogadrosNumb, kDeltaNuCs, ... One could certainly argue that, since the constants are already in the Constants name space, they can be easily identified as constants. Anyhow, I think there's an advantage of indicating the constant nature of these variables in their name and to do this consistently with other constants defined in the code. If none of the other developers opposes this, I would go on to rename the constants defined in constants.[h, cc] and others I find in the code to homogenize this. Looking forward to your input! Regards, Simon _______________________________________________ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de<mailto:arts_dev.mi@lists.uni-hamburg.de> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
_______________________________________________ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
