rearrangment/reformat of the source code

[nbehrnd]

To ease contributions to the project, a style which can be checked by fprettify
(see equally style file fprettify.rc) is proposed.

[nbehrnd]

There are separate subroutines set_height and set_width about the images, naturally, allocate_pixels uses both of them. In review of the changes proposed above, I start to like the idea set_height and set_width could coalesce into one subroutine in common (e.g., set_dimensions) which manages both parameters in a single array in one place only.

What do you think about this?

[gha3mi]

Thanks @nbehrnd

Personally, I use VSCode as my code editor with the Modern Fortran Extension. Modern Fortran, by default, uses findent for formatting. However, it is also possible to use fprettify within this extension. I haven't modified the default formatting settings, but I am open to using your suggested formatting style. (This is my personal idea, but we can discuss it further: we could apply a formatting process during the review stage after a pull request (PR) is sent. This way, developers can focus on coding, and during the review process, we can suggest or implement the desired formatting style.)

Sorting all procedures alphabetically can be a bit difficult in the future. If the name of a subroutine changes, then the position of the subroutine will also change.

Regarding the set_dimension procedure, I believe it is possible to add a new subroutine for set_dimension without removing set_height and set_width. This gives users or developers the ability to set only height or width if needed in the future. Alternatively, we could create a set_dimension subroutine with optional height and width parameters.

 elemental pure subroutine set_dimension(this, height, width)
    class(format_pnm), intent(inout) :: this
    integer, intent(in), optional :: height
    integer, intent(in), optional :: width

    if (present(height)) this%height = height
    if (present(width)) this%width = width
 end subroutine set_dimension

To discuss all topics separately, please open an issue for each topic. This way, we can discuss each topic individually before sending a PR and merging it into the main branch.

[nbehrnd]

@gha3mi My suggestion of fprettify is biased because of an encounter in ABIN as file .fprettify.rc where the explicit list of all parameter (levels) aim to provide the same result regardless if defaults of fprettify would change. And a PR (https://github.com/pseewald/fprettify/pull/146) to fprettify as initiated by Patrick Seewald. (I don't know how much he is envolved in other projects on GitHub where this string appears in name.) This being said, because findent nicely works from the CLI, I'm fine to use it here instead. From a test on forimage.f90 as currently in branch main, it looks like you run it with the defaults of parameters; ok. Because of partially clipped lines in html pages generated by ford (e.g., about example1.f90), though one can use a slider to access the initially invisible part, I'm still in favour of a (manual) line break after 80 characters.

The alphabetic sort of the procedures was a brief sort by vim of the lines in the type block marked with subsequent copy-yank of the procedures per sé below for consistency. With the earlier listing in hand (in the type block), however, easy enough to pick up the procedure's name and to retrieve it further down in the module.

I now understand the separate management of set_height and set_width as the safer approach than both parameters in one common procedure (alone) and hence retract the idea to coalesce the two.