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> 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 > 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
