On `use different styles concurrently`

[muellermichel]

First of all, Stefano and everyone suppporting here, I think you are doing a great job, I think this sort of effort has long been missing in the FORTRAN community. Wanted to get that out of the way first.

Here's something I noticed in the current README:

use different styles concurrently

-- if you mix camel case and underscore style in a case insensitive language, doesn't that mean that the compiler gets confused as soon as you have single word modules / types? If that assumption is correct I'd advocate against doing this mix.

[szaghi]

@muellermichel thank you, but the effort is collaborative, we (Zaak/Chris/me) are only collecting your idea.

if you mix camel case and underscore style in a case insensitive language, doesn't that mean that the compiler gets confused as soon as you have single word modules / types?

I am sorry, but I am not able to follow you. What does mean compiler gets confused?

[muellermichel]

let's take a single word name Car (camel case). The 'underline' version would then be car. This wouldn't be acceptable, would it? So you'd have to use car_m and car_t - meaning that the CamelCase vs. underline approach doesn't seem to work in general. Or am I missing something?

[szaghi]

@muellermichel oh, sure now I see: underscore is surely more general than CamelCase when talking about a language that is case insensitive. The thing that confused me in you original post was the reference to compiler. I think that the starting point is that

Fortran is case insensitive, thus do no rely on only CamelCase to distinguish different entities, because integer :: Day is the same of integer :: day for example.

If you (all of you) like to add modification to the README, feel free to do it.

[zbeekman]

Yes I think that we should all feel free to modify the document, but we should try to have the document remain true to our conversations in the issues section. Not an easy task. Thanks @szaghi for taking the lead on this. I hope to have a pass through it this weekend (during the snow storm! ❄️ ⛄ ) and integrate various parts.

[muellermichel]

@szaghi well my modification would be to simply remove this section for the reason I mentioned, which is why I wanted to discuss it first. Would you agree then that it should be removed?

[szaghi]

@muellermichel My vote is to amend it, rather than to eliminate 😄

[muellermichel]

Alright, I amended it. However IMO a best practices guide should promote a coding style that is as robust as possible, which this style violates - unless I'm missing something.

[szaghi]

@muellermichel Thank you very much, I agree. Indeed I am fine also removing this subsection. Let us wait for other comments, especially the comments of sho like CamelCase.

[Tobychev]

For the specific example in Entities disambiguation, I think the guide should say something like "in the case where type and a module would share name, always name the latter so it is clear that it is a module, ie by affixing a mod pre- or suffix". This is because in the choice between mangling the module or the type name (or both), I think it is important to keep the type name semantically clean, while I don't know of a context where module names are used that a few extra letters makes a line harder to understand.

(Also, in the special case of a one word name, either you cannot apply camelCase / under_score because these are rules about how to join more an one word, or it would be _car / [Cc]ar because you join the name with the "empty word".)