Enforcing Fortran Style

[Ilie__Daniel]

Hello!

Does anybody know of any Fortran Style Enforcing Programs? Can they be integrated in Visual Studio?
I know that Microsoft Style Cop can be used to enforce C# styles and integrates with Visual Studio.

Kind regards,
Daniel.

[holmz]

I am actually looking for a style guide.

I recall Tom Lahey's suggestions...

I use upper case for IF, ENDIF, DO, SUBROUTINE, TRANSPOSE, etc. for all the Fortran intrinsics. And therefore lower case or mixed case for my Functions, Subroutines, and Variables. e.g.

REAL(KIND=8) :: MyTime

CHARACTER(LEN=24) ::Acsii_Time

And for arguments spaces after the commas. e.g.:
CALL my sub(a, b, c, d)

But interested in whether there are any standards at all?

And if so where those might be posted??

[dboggs]

I too would like to find a style guide(s) or at least more discussion of this topic. I am very conscious of consistent style in my own programs and hate the thoughts of how I should type certain names, comments etc. on the fly--"wait, is this how I've been doing this lately, is that what I decided would be my standard, etc."

I absolutely detest codes that are entirely lowercase. Especially if not sprinkled with character spacing and line spacing (but doing this consistently raises many questions). I know this trend began under the assumption that it was easier to read than uppercase, but I disagree. I use many comments, especially multiline comments, and THESE should read like text and be easily distinguishable from code at a mere glance.

I have been influenced by participating in this forum. Like holmz, I started using UPPERCASE for all Fortran keywords (also intrinsic functions) and lowercase for my own variables and procedure names. I like this style very much and wish more people did it. I try to extend it by using uppercase for everything that I cannot/should not change, such as library procedures from IMSL. Lowercase is reserved for all names that are up to me.

I always try to begin all integer variables with I - n like in the old days, even though current emphasis on using IMPLICIT NONE makes this unnecessary, because it is very useful to attach flags like this to names so that I don't have to go and check the declarations section look up the type. Similarly, try to use a leading cap for variables that are arrays and derived types. I would love to start all character strings with a '$'. This is possible in IVF by extension, but it is not standard so I abandoned this style.

There are many issues that I don't have a consistent style for. Having one written down helps--as would having one widely followed by others, having one that was published or at least widely recommended.

[jimdempseyatthecove]

iAnyIntegerVariabeNameHere

rMakesSenseForRealsToo

sCouldBeUsedForSrings

Jim Dempsey

[FortranFan]

One could argue the points in the OP and in quotes #1 and #2 fall largely in the category of "code refactoring" for which Fortran-specific tools are few and far in between.  However, I find one really good tool that has recently become available is the Fortran plug-in for Code::Blocks created by Darius Markauskas and offered at http://darmar.vgtu.lt/.  In addition to many cool IDE features that it offers with Code::Blocks, a couple of features it offers is "Change Case" and "Fortran Indent" which are really cool in my opinion.

[Simon_Geard]

After many decades of experience writing code (mainly Fortran, C++ and Tcl) I'd say be very careful about imposing style. The use of letter case in names is an excellent example - I hate it. I used to program like that but I find the mixture of case makes the code look confused and acts as a barrier to understanding. I know the language - I don't need something to be written in uppercase to tell me it is a language component; the use of colour in the editor is quite sufficient for that. On the other hand providing extra information can be useful, for example pre- or post- fixing derived type variable names or variables that are pointers. Prefixing a variable to indicate its type is driving straight towards the idea of Hungarian notation and as such is to be avoided. I use names that are, as far as possible, germane to the task at hand so that I (almost) never start a logical variable with 'l' and reserve i, j, k etc for dummy loop counters.

No doubt there will be many people who disagree with me but that is just the point. Imposing style on developers does nothing except annoy the developers and can easily bring discord to a previously harmonious team - it does not make the code easier to maintain or less prone to bugs. The other aspect of this is that it is far too easy to mistake programming style for programming practice. Good developers can read good code in any reasonable style and write code that is clear and maintainable even if it's not in your preferred style.

There are two things the VS integration could do to help both of which have been in xemacs for decades:

1. tabbed completion of 'end'
2. 'indent region' which indents the selected region (which could be the whole file)

[Steven_L_Intel1]

Indent region is already in VS. Just select the region and hit Tab. To un-indent, use shift-Tab.

We also support "snippets" so you can type, for example:

sub<tab>

and you'll get:

   subroutine Sub()
    ! Variables
    
    ! Body of Sub
    
    end subroutine Sub

with the name "Sub" highlighted. Change the name to whatever you want and the name will automatically change in the comment and the end statement.

[andrew_4619]

Hmmm didn't know about the code snippets that looks interesting. I did not find anything in the help are there some guides.

I note from a quite test that there are func sub and mod snippets, are there any more?

[IanH]

Within VS, give Tools > Code Snippets Manager a whirl.

[Steven_L_Intel1]

There are a bunch. RIght click in the text editor and select Insert Snippet. Click on one in the list to see description and shortcut, double-click to insert. (Or type the shortcut followed by <tab>.)

Definitions are in C:\Program Files (x86)\Microsoft Visual Studio 12.0\Intel Fortran\Snippets\Snippets (that's for VS2013, substitute as necessary.)

[andrew_4619]

Cheers guys, useful :-)

So many features in VS, always new stuff to find....