Provide snake_case procedure names for all public methods.

[tclune]

While there are many fans of CamelCase, a strong argument can be made that it is inappropriate for case-insensitive languages. The style I have adopted is for ClassNames to be CamelCase, and methods/variables to be snake_case. For backward compatibility, CamelCase will be be retained until pFUnit 5.0

[Leonard-Reuter]

CamelCase for class names and snake_case for methods/variables looks like an adaptation of PEP 8 for Fortran, which I think is the way to go =). However, I would encourage to apply rule 7.2 from Modern Fortran - Style and Usage:

Capitalize the names of all user-written procedures.

This is quite Fortran specific and recommended in order to distinguish array access from function calls (ie. atoms(i) accesses an array, while Atoms(i) accesses a function–of ourse I cannot and should not use both in the same code). Other programming languages distinguish them via different brackets.

PS: I know, this problem is not that severe with proper function names, but capitalization still improves readability.

[tclune]

Side comment: I've been a bit negligent in pushing the snake_case throughout the source code. I'd best do that soon, or it will be hard to argue against retaining CamelCase in 5.0 down the road.

Thank you - I do appreciate constructive suggestions about style. Occasional debates are even enjoyable, though more so in person than in text exchanges. This is the first time I've encountered an argument for capitalizing user procedures. I can see some advantage, but I'll be honest that changing style is problematic for me on several fronts. Mostly just old habits are hard to change, but there is also a lot of code that would need to change. But there's also the school of thought that classes/types are "proper nouns" (and thus capitalized), variables are regular nouns (lower case), and procedures are verbs (lower case). Not an overwhelming argument to be sure, but it is the main rationale for retaining CamelCase for types.

Your distinction is particularly minor in pFunit given my usual conventions. All data components are private, and externally accessible procedures are type-bound. Thus foo%bar(...) in an expression context must be a procedure. Access to arrays is limited to the inner-workings of pFUnit. (And even then raw arrays are relatively rare in pFUnit. I tend to use gFTL containers as few entities have known sizes at the time of their creation.)

I will continue to ponder your suggestion, and will watch for that style when I look at other examples. And certainly welcome additional discussion on the topic. Esp. if additional users have strong (but well-intentioned) opinions.