Naming convention: usr and user

[timofeymukha]

Hi! Started looking a bit at the code as a Friday afternoon activity. I'm wondering if it could be possible to harmonize the naming of routines pertaining to the "user". Similarly to Nek5000, there seems to be 2 versions: usr and user. It became apparent when looking at the tgv example:

  6   subroutine user_setup(u)
  7     type(user_t), intent(inout) :: u
  8     u%fluid_usr_ic => user_ic
  9     u%usr_msh_setup => user_mesh_scale
 10     u%usr_chk => usr_calc_quantities
 11   end subroutine user_setup

So, here most of the internal stuff is actually usr, except for user_t. Looking at user_intf.f90 there is plenty of examples of both as well. This sounds like a small thing, but I still experience cognitive strain in Nek5000 when trying to recall that it is userbc but usrdat. I would personally suggest just using user throughout, there is really little justification to save 1 letter in a variable name.

I think it is generally a great idea to use very verbose variable names and not copy over variable names that are in Nek5000. I realize the latter is good for those coming over from Nek5000, but in the long run I think verbosity will do everyone a favour.

[timofeymukha]

As an illustration of the general verbosity level that I think would be good, here is a rewrite of the beginning of statistics.f90

module statistics
  use numerical_types
  use statistical_quantity
  implicit none

  !> Pointer to an arbitrary quantitiy
  type, private :: quantity_ptr_t
     class(statistical_quantity_t), pointer :: quantity_ptr
  end type quantity_ptr_t

  !> Statistics backend
  type :: statistics_t
     type(quantity_ptr_t), allocatable :: quantity_list(:)
     integer :: n_quantities
     integer :: size
     real(kind=rp) :: start_time
   contains
     procedure, pass(this) :: init => statistics_init
     procedure, pass(this) :: free => statistics_free
     procedure, pass(this) :: add => statistics_add
     procedure, pass(this) :: eval => statistics_eval
  end type statistics_t

I realize that this is highly subjective, and maybe I didn't choose the best piece of the code to illustrate the point. But at least for me, this is much easier to read. Of course, I don't mean that everything has to be rewritten in this way, but since development is very active, and we are still early in the process, I think a discussion could be good to have.

[MartinKarp]

I agree with what you are saying, especially for the functions that a user will use a lot. There is a point in keeping some naming conventiones e.g. from math to make it easier to use old code and tools, but for the new things it might be good to be more verbose. What do you think Niclas?

[pschlatt1]

I realise that I opened an issue with the same topic, sorry about that (issue #632). Generally, I recommend to use "user" etc. as we do not have a 6 character limitation anymore...