There was a lot going on in my f90 module with pointers to set the targets of the datapool variables to the correct locations in shared memory. But I agree, off-topic for this thread.
Personally I see little wrong with using a DATA statement except that you can partially fill one, which can lead to bugs (or be considered a useful feature in a few places) and that there are so many extensions associated with DATA statements that they can lead to portability problems. But you cannot use them to declare constants, and people new to Fortran do not always understand what a saved variable implies. So if something is a constant I think you should declare it in a declaration with the parameter attribute. If you are only initializing a few values a declaration on one line is clearer to me. But I personally do not feel there is a great need to remove them like a COMMON block or GOTO and CONTINUE statements that are just defining simple loops (which I think really detract from readability even if they work). That being said, I hardly ever use them in new code. I do like the repeat syntax of a DATA statement compared to implied DOs in a declaration when initializing arrays, and I think filling an array in row-column order looks much better with DATA statements versus a type declaration.
2 Likes
The simple solution here is to mark specific commits as not important for diff statements.
See e.g. .git-blame-ignore-revs for git repos.
I cannot live without a formatter anymore and I think it is neccesary that a software project has a consistent formatting style.
lfortran is one of my favorite projects in Fortran space, but I think it is a very sophisticated tool for the purpose of just indentation and I had a case when it mangled my code (unfortunately I did not distill a bug report and now I do not remember which file caused the issue). Since then i stick to findent, maybe it is stupid but I really feel safer when my formatter just takes care of just whitespaces.
Regarding some of the closed-source tools mentioned here, consider this my personal opinion but I think that âif it is not free software it does not matterâ â any software which may not be freely downloaded or modified effectively is out of the picture when it comes to widespread adoption. For small and frequently used tools like code formatters, this is especially true. (One of the reason I keep my code compatible with gfortran, as much pain as it might cause â otherwise I would restrict the freedom of an end-user to use my software).
3 Likes
Thatâs expected while we are still in alpha. We are working super hard to get to beta, and there wonât be bugs like these. In the meantime, please definitely report all such cases, so that we can fix them.
3 Likes
Hello everyone!
Thank you all for your great input on this topic. Itâs been really helpful to see the variety of tools and preferences in use. For us, one key takeaway is the absence of a âstandardizedâ workflow for formatting Fortran code.
Considering this, we at Codee are developing Codee Format, a free feature integrated into our platform for code correctness, modernization, security, and optimization. Our goal is to support the Fortran ecosystem by providing a formatter for seamless, consistent, and highly customizable code formatting.
We would love your input in shaping Codee Format. Weâre looking for beta testers to collaborate with us by offering feedback and suggestions, helping ensure this formatter effectively meets the needs of the community. If youâre interested, you can join the beta tester program here!
Thank you for all the discussions so far. Weâre really excited to work together and see how we can continue contributing to the Fortran ecosystem!
3 Likes