{"action":"created","issue":{"url":"https://api.github.com/repos/Fortran-FOSS-Programmers/Best_Practices/issues/5","labels_url":"https://api.github.com/repos/Fortran-FOSS-Programmers/Best_Practices/issues/5/labels{/name}","comments_url":"https://api.github.com/repos/Fortran-FOSS-Programmers/Best_Practices/issues/5/comments","events_url":"https://api.github.com/repos/Fortran-FOSS-Programmers/Best_Practices/issues/5/events","html_url":"https://github.com/Fortran-FOSS-Programmers/Best_Practices/issues/5","id":126100896,"number":5,"title":"Naming Conventions, which one?","user":{"login":"szaghi","id":1661942,"avatar_url":"https://avatars.githubusercontent.com/u/1661942?v=3","gravatar_id":"","url":"https://api.github.com/users/szaghi","html_url":"https://github.com/szaghi","followers_url":"https://api.github.com/users/szaghi/followers","following_url":"https://api.github.com/users/szaghi/following{/other_user}","gists_url":"https://api.github.com/users/szaghi/gists{/gist_id}","starred_url":"https://api.github.com/users/szaghi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/szaghi/subscriptions","organizations_url":"https://api.github.com/users/szaghi/orgs","repos_url":"https://api.github.com/users/szaghi/repos","events_url":"https://api.github.com/users/szaghi/events{/privacy}","received_events_url":"https://api.github.com/users/szaghi/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/Fortran-FOSS-Programmers/Best_Practices/labels/question","name":"question","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":23,"created_at":"2016-01-12T05:19:01Z","updated_at":"2016-01-12T21:43:18Z","closed_at":null,"body":"This is probably one of the most personal guideline. \r\n\r\nI have to admit that I have not yet found yhe one that I love so I often change my mind resulting into somehow disorder style (that really hurts my soul).\r\n\r\nI read about many nice idea. I will try to report them here (I need some times, but do not wait me, start suggestiong your convention) in order to promote our discussion.\r\n\r\n#### From one of the @cmacmackin [guides](https://github.com/Fortran-FOSS-Programmers/FIAT/wiki/Style-Guidelines#naming-conventions)\r\n> + Names should be descriptive, especially for publicly visible entities. Underscores should be used to separate words if a name is more than two words long. If a name is only two words long then an underscore may be used at your discretion. Sometimes they make the name more readable, sometimes they just make it longer. As with anything else in the code, use lower cases characters only.\r\n> + For identifiers avoid to exploit *Case* to indicate different words within them when Fortran is case-insensitive, the language doesn't recognize it.\r\n\r\n#### From @certik [best practices](http://www.fortran90.org/src/best-practices.html)\r\n> + Use lowercase for all Fortran constructs (`do, subroutine, module`, ...).\r\n> + as consequence from lowercase adoption, exploit underscores rather than `camelCase`.\r\n> + but the except is to follow short mathematical notation for mathematical variables/functions (`Ylm, Gamma, gamma, Enl, Rnl`, ...).\r\n> + For other names use all lowercase: try to keep names to one or two syllables; if more are required, use underscores to clarify (`sortpair, whitechar, meshexp, numstrings, linspace, meshgrid, argsort, spline, spline_interp, spline_interpolate, stoperr, stop_error, meshexp_der`).\r\n> + `camelCase` for variables comes from Java and I pretty strongly do not recommend it.\r\n\r\n#### From @milancurcic best practices\r\n> + reserved Fortran words in all uppercase \r\n> + variables lower-case\r\n> + underscores for multi-word variables\r\n> + camelCase for procedure names\r\n\r\n```fortran\r\nTYPE :: datetime\r\n\r\n  INTEGER :: year        = 1 ! Year                   [1-HUGE(year)]\r\n  INTEGER :: month       = 1 ! Month in year          [1-12]\r\n  INTEGER :: day         = 1 ! Day in month           [1-31]\r\n  INTEGER :: hour        = 0 ! Hour in day            [0-23]\r\n  INTEGER :: minute      = 0 ! Minute in hour         [0-59]\r\n  INTEGER :: second      = 0 ! Second in minute       [0-59]\r\n  INTEGER :: millisecond = 0 ! Milliseconds in second [0-999]\r\n\r\n  REAL(KIND=real_dp) :: tz = 0 ! Timezone offset from UTC [hours]\r\n\r\n  CONTAINS\r\n\r\n  PROCEDURE :: addMilliseconds\r\n  PROCEDURE :: addSeconds\r\n  PROCEDURE :: addMinutes\r\n  PROCEDURE :: addHours\r\n  PROCEDURE :: addDays\r\n  PROCEDURE :: isocalendar\r\n  PROCEDURE :: isoformat\r\n  PROCEDURE :: isValid\r\n  PROCEDURE :: now\r\n  PROCEDURE :: secondsSinceEpoch\r\n  PROCEDURE :: strftime\r\n  PROCEDURE :: tm\r\n  PROCEDURE :: tzOffset\r\n  PROCEDURE :: utc\r\n  PROCEDURE :: weekday\r\n  PROCEDURE :: weekdayLong\r\n  PROCEDURE :: weekdayShort\r\n  PROCEDURE :: yearday\r\n\r\nENDTYPE datetime\r\n```\r\n\r\n#### From @rouson best practices\r\n> + prefer all lowercase\r\n> + prefer *underscores* over camelCase => `add_milliseconds` over `addMilliseconds`\r\n> + use mixed case in situations where underscores are not allowed, e.g., in defined operators and in `name=` field of *bind(C)* pricedures when applicable:\r\n```fortran\r\ntype foo\r\ncontains\r\n   procedure :: negate_foo\r\n   generic :: operator(.negateFoo.) => negate_foo\r\nend type\r\n```\r\n> + procedure names must have an action verb in them.\r\n> + logical variables must be named to reflect the state they are used to convey, most with the verb *to be*, e.g. :\r\n>       - `lib_is_initialized` vs `lib_init`;\r\n>       - `obj_has_parent` vs `obj_parent`;\r\n> + do not strive to much in *local shortening* of variables name, prefer meaningful name: local shortening is often possible with the `associate` construct.\r\n> + avoid single character suffix for types and modules, e.g. `_t` and `_m`, because:\r\n>     - a single character has the lowest information entropy possible in a language.   Probably for this reason, conveying meaning with a single character is bound to confuse anyone who is not already familiar with the convention.\r\n>     - I have no problem with borrowing from other languages, but there just aren’t enough Fortran programmers doing this for it to be widely a widely recognizable convention. \r\n> + on the contrary prefer suffix like `_interface` to module names and `_implementation` to submodule names.\r\n\r\n#### From @victorsndvg  best practices\r\n> + exploit *camelCase* over underscores;\r\n> + prefer a complete meaningful *action-descriptive* name for procedures, even if the resulting name is very very long, e.g. `PerformAnActionWithThisVariableOfTypeXXXWhileThisContext`\r\n> + prefix type bound procedures (TBP) with the type name for allowing an easy *refactoring* of codes (it becomes very easy to move *class* from a module into a new one without change the procedures names), e.g.\r\n```fortran\r\ntype :: my_object\r\ncontains\r\n  procedure :: action => my_object_PerformAnActionWithThisVariableOfTypeXXXWhileThisContext\r\nend type\r\n```\r\n\r\n#### From @zbeekman best practices\r\n> + exploit `camelCase` for procedures to be able to immediately identify an entity as a procedure.\r\n> + names must have meaning.\r\n> + procedure names must have an action verb in them.\r\n> + named constants (parameters?) are in `UPPERCASE`.\r\n> + logical variables must be named to reflect the state they are used to convey, most with the verb *to be*, e.g. :\r\n>       - `lib_is_initialized` vs `lib_init`;\r\n>       - `obj_has_parent` vs `obj_parent`;\r\n> + append `_t` to derived type names and `_m` to module names to help *namespace*: you can have modules with effectively the same name as the class they implement, and one could even declare an object with the same name as the derived type/class if one wanted to do so; also the `_t` is a common convention in some other languages like C.\r\n\r\n#### From @LadaF best practices\r\n> + prefer undescores over `camelCase` due to consistency with the Fortran standard naming convention and the case insensitivity of names Fortran.\r\n> + structure constructors and other similar function should **not** have any verb in them, their name is just what they return, due to consistency with the Fortran standard default and overloaded structure constructors naming.\r\n> + avoid module suffixes, expect (maybe) for type names *disambiguation*, e.g.\r\n```fortran\r\ntype(Sphere) :: sphere ! won't work\r\ntype(spere_t) :: sphere ! works\r\n```\r\n\r\n#### From @tclune best practices\r\n> + prefer undescores over `camelCase` due to consistency with the Fortran standard naming convention and the case insensitivity of names Fortran.\r\n> + however, `camelCase` could be admissible for module names and type names; in fact, type names are *proper nouns* in the language, and as such, I at least one to capitalize them; moreover, `camelCase` helps to accentuate this when the noun is multiple words; but more importantly it often solves type names *disambiguation*, e.g.\r\n```fortran\r\ntype (SphereShape) :: sphere_shape ! or just sphere\r\n```\r\n> + append `_t` to derived type names to disambiguation aims could be help, it could be considered superfluous, i.e. my usual pattern is to define one “class” per Fortran module prefix `pkg_`  (over suffix with `_mod`) for all modules in the package, e.g.\r\n```fortran\r\nmodule pkg_SphereShape_mod\r\n...\r\ntype :: SphereShape\r\n```"},"comment":{"url":"https://api.github.com/repos/Fortran-FOSS-Programmers/Best_Practices/issues/comments/171067562","html_url":"https://github.com/Fortran-FOSS-Programmers/Best_Practices/issues/5#issuecomment-171067562","issue_url":"https://api.github.com/repos/Fortran-FOSS-Programmers/Best_Practices/issues/5","id":171067562,"user":{"login":"szaghi","id":1661942,"avatar_url":"https://avatars.githubusercontent.com/u/1661942?v=3","gravatar_id":"","url":"https://api.github.com/users/szaghi","html_url":"https://github.com/szaghi","followers_url":"https://api.github.com/users/szaghi/followers","following_url":"https://api.github.com/users/szaghi/following{/other_user}","gists_url":"https://api.github.com/users/szaghi/gists{/gist_id}","starred_url":"https://api.github.com/users/szaghi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/szaghi/subscriptions","organizations_url":"https://api.github.com/users/szaghi/orgs","repos_url":"https://api.github.com/users/szaghi/repos","events_url":"https://api.github.com/users/szaghi/events{/privacy}","received_events_url":"https://api.github.com/users/szaghi/received_events","type":"User","site_admin":false},"created_at":"2016-01-12T21:43:17Z","updated_at":"2016-01-12T21:43:17Z","body":"@rouson thanks a lot!\r\n\r\nTwo things:\r\n\r\n+ in the case subroutine *speack* has a passed class the submodule should *use* module? I guess it does not because it is declared into the *submodule of the module*, I guess right the compilation cascade is *submodule => module => program* from lowest yo highest, right?\r\n+ make a blog, make a blog, make a blog! :pray: "}}