Hi Richard,

Thanks for your feedback. I agree that we should try to get rid of constants.cc 

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.



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,

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 

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 

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 

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 

defined in constants.[h, cc] and others I find in the code to homogenize this.

Looking forward to your input!



arts_dev.mi mailing list
arts_dev.mi mailing list

Reply via email to