Improve code readability

[manodeep]

While looking at the source code as part of #6 , I see that the readability for these lines could be improved significantly. Existing code:

#ifdef NO_QUAD_PRECISION
  double px, py, pz, qx, qy, qz, ddd;
#ifndef SQRT_
#define SQRT_ sqrt
#else
#error "SQRT_ Previously Defined"
#endif  /* SQRT_ */
#ifndef ABS_
#define ABS_ fabsl
#else
#error "ABS_ Previously Defined"
#endif  /* ABS_ */
#else
  long double px, py, pz, qx, qy, qz, ddd;
#ifndef SQRT_
#define SQRT_ sqrtl
#else
#error "SQRT_ Previously Defined"
#endif  /* SQRT_ */
#ifndef ABS_
#define ABS_ fabs
#else
#error "ABS_ Previously Defined"
#endif  /* ABS_ */
#endif

My suggestion would be to re-write as - which makes the code concise, performs error-checking first (instead of inter-mixing with actual code) and make the code more readable (while also fixing #6):

#if defined(SQRT_) || defined(ABS_) 
#error SQRT_ or ABS_ should not be defined
#endif


#ifdef NO_QUAD_PRECISION
#define VARTYPE_ double
#define SQRT_ sqrt
#define ABS_ fabs
#else
#define VARTYPE_ long double
#define SQRT_ sqrtl
#define ABS_ fabsl
#endif

  VARTYPE_ px, py, pz, qx, qy, qz, ddd;

Might also be worthwhile to add an #undef VARTYPE_ at the end of the function

Related: I see that the arccos is always set to acosl here rather than acosl or acos depending on the value of NO_QUAD_PRECISION. Perhaps that is intentional - @chrisb13?

[chrisb13]

Sorry @manodeep just saw this.

I'm not across this part of FMS (@ACCESS-NRI/ocean) but if you haven't seen them, there are some coding guidelines here. I would think that if the above is inconsistent with those then you have grounds for a PR / GH issue.

[dougiesquire]

If you do submit a PR @manodeep, I think it should go to the upstream NOAA-GFDL/FMS:main. I think differences between our fork main and upstream should only be ACCESS-specific things that we can't get accepted upstream.

[manodeep]

Thanks @chrisb13 and @dougiesquire. To be clear, I was not planning to make these changes myself - I noticed the potential improvements and suggested what might be a reasonable option (same applies to #6).