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.


> 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

Reply via email to