Hi Simon, How should I proceed with the reformatting with clang-format? Should I go ahead, or should we postpone it as well? I don't want to create a whole bunch for merge issues for you.
Cheers, Oliver > On 2 Sep 2019, at 07:08, Simon Pfreundschuh <simon.pfreundsc...@chalmers.se> > wrote: > > 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> 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 _______________________________________________ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
