Re: [arts-dev] Renaming of constants

2019-09-02 Thread Simon Pfreundschuh
Just go ahead,


I have only changed constants.h so far, so merging the code won't be difficult.


Regards,


Simon


From: Oliver Lemke 
Sent: Monday, September 2, 2019 7:27:26 AM
To: Simon Pfreundschuh
Cc: Richard Larsson; ARTS Development List
Subject: Re: [arts-dev] Renaming of constants

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

Re: [arts-dev] Renaming of constants

2019-09-01 Thread Oliver Lemke
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  
> 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 
> 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 
>  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

Re: [arts-dev] Renaming of constants

2019-08-27 Thread Richard Larsson
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