├── .gitignore ├── LICENSE-CC-by-sa.md ├── LICENSE-CC0.md ├── License-considerations.md └── README.md /.gitignore: -------------------------------------------------------------------------------- 1 | references/ 2 | -------------------------------------------------------------------------------- /LICENSE-CC-by-sa.md: -------------------------------------------------------------------------------- 1 | ## creative commons 2 | 3 | # Attribution-ShareAlike 4.0 International 4 | 5 | Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible. 6 | 7 | ### Using Creative Commons Public Licenses 8 | 9 | Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses. 10 | 11 | * __Considerations for licensors:__ Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. [More considerations for licensors](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensors). 12 | 13 | * __Considerations for the public:__ By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. [More considerations for the public](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensees). 14 | 15 | ## Creative Commons Attribution-ShareAlike 4.0 International Public License 16 | 17 | By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. 18 | 19 | ### Section 1 – Definitions. 20 | 21 | a. __Adapted Material__ means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. 22 | 23 | b. __Adapter's License__ means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. 24 | 25 | c. __BY-SA Compatible License__ means a license listed at [creativecommons.org/compatiblelicenses](http://creativecommons.org/compatiblelicenses), approved by Creative Commons as essentially the equivalent of this Public License. 26 | 27 | d. __Copyright and Similar Rights__ means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. 28 | 29 | e. __Effective Technological Measures__ means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. 30 | 31 | f. __Exceptions and Limitations__ means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. 32 | 33 | g. __License Elements__ means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike. 34 | 35 | h. __Licensed Material__ means the artistic or literary work, database, or other material to which the Licensor applied this Public License. 36 | 37 | i. __Licensed Rights__ means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. 38 | 39 | j. __Licensor__ means the individual(s) or entity(ies) granting rights under this Public License. 40 | 41 | k. __Share__ means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. 42 | 43 | l. __Sui Generis Database Rights__ means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. 44 | 45 | m. __You__ means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. 46 | 47 | ### Section 2 – Scope. 48 | 49 | a. ___License grant.___ 50 | 51 | 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: 52 | 53 | A. reproduce and Share the Licensed Material, in whole or in part; and 54 | 55 | B. produce, reproduce, and Share Adapted Material. 56 | 57 | 2. __Exceptions and Limitations.__ For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 58 | 59 | 3. __Term.__ The term of this Public License is specified in Section 6(a). 60 | 61 | 4. __Media and formats; technical modifications allowed.__ The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. 62 | 63 | 5. __Downstream recipients.__ 64 | 65 | A. __Offer from the Licensor – Licensed Material.__ Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. 66 | 67 | B. __Additional offer from the Licensor – Adapted Material. Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply. 68 | 69 | C. __No downstream restrictions.__ You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 70 | 71 | 6. __No endorsement.__ Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). 72 | 73 | b. ___Other rights.___ 74 | 75 | 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 76 | 77 | 2. Patent and trademark rights are not licensed under this Public License. 78 | 79 | 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. 80 | 81 | ### Section 3 – License Conditions. 82 | 83 | Your exercise of the Licensed Rights is expressly made subject to the following conditions. 84 | 85 | a. ___Attribution.___ 86 | 87 | 1. If You Share the Licensed Material (including in modified form), You must: 88 | 89 | A. retain the following if it is supplied by the Licensor with the Licensed Material: 90 | 91 | i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); 92 | 93 | ii. a copyright notice; 94 | 95 | iii. a notice that refers to this Public License; 96 | 97 | iv. a notice that refers to the disclaimer of warranties; 98 | 99 | v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; 100 | 101 | B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and 102 | 103 | C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. 104 | 105 | 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 106 | 107 | 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. 108 | 109 | b. ___ShareAlike.___ 110 | 111 | In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply. 112 | 113 | 1. The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License. 114 | 115 | 2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material. 116 | 117 | 3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply. 118 | 119 | ### Section 4 – Sui Generis Database Rights. 120 | 121 | Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: 122 | 123 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; 124 | 125 | b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and 126 | 127 | c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. 128 | 129 | For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. 130 | 131 | ### Section 5 – Disclaimer of Warranties and Limitation of Liability. 132 | 133 | a. __Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.__ 134 | 135 | b. __To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.__ 136 | 137 | c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. 138 | 139 | ### Section 6 – Term and Termination. 140 | 141 | a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. 142 | 143 | b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 144 | 145 | 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 146 | 147 | 2. upon express reinstatement by the Licensor. 148 | 149 | For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. 150 | 151 | c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. 152 | 153 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. 154 | 155 | ### Section 7 – Other Terms and Conditions. 156 | 157 | a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. 158 | 159 | b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.t stated herein are separate from and independent of the terms and conditions of this Public License. 160 | 161 | ### Section 8 – Interpretation. 162 | 163 | a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. 164 | 165 | b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. 166 | 167 | c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. 168 | 169 | d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. 170 | 171 | ``` 172 | Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at [creativecommons.org/policies](http://creativecommons.org/policies), Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses. 173 | 174 | Creative Commons may be contacted at creativecommons.org 175 | ``` -------------------------------------------------------------------------------- /LICENSE-CC0.md: -------------------------------------------------------------------------------- 1 | ## creative commons 2 | 3 | # CC0 1.0 Universal 4 | 5 | ``` 6 | CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED HEREUNDER. 7 | ``` 8 | 9 | ### Statement of Purpose 10 | 11 | The laws of most jurisdictions throughout the world automatically confer exclusive Copyright and Related Rights (defined below) upon the creator and subsequent owner(s) (each and all, an "owner") of an original work of authorship and/or a database (each, a "Work"). 12 | 13 | Certain owners wish to permanently relinquish those rights to a Work for the purpose of contributing to a commons of creative, cultural and scientific works ("Commons") that the public can reliably and without fear of later claims of infringement build upon, modify, incorporate in other works, reuse and redistribute as freely as possible in any form whatsoever and for any purposes, including without limitation commercial purposes. These owners may contribute to the Commons to promote the ideal of a free culture and the further production of creative, cultural and scientific works, or to gain reputation or greater distribution for their Work in part through the use and efforts of others. 14 | 15 | For these and/or other purposes and motivations, and without any expectation of additional consideration or compensation, the person associating CC0 with a Work (the "Affirmer"), to the extent that he or she is an owner of Copyright and Related Rights in the Work, voluntarily elects to apply CC0 to the Work and publicly distribute the Work under its terms, with knowledge of his or her Copyright and Related Rights in the Work and the meaning and intended legal effect of CC0 on those rights. 16 | 17 | 1. __Copyright and Related Rights.__ A Work made available under CC0 may be protected by copyright and related or neighboring rights ("Copyright and Related Rights"). Copyright and Related Rights include, but are not limited to, the following: 18 | 19 | i. the right to reproduce, adapt, distribute, perform, display, communicate, and translate a Work; 20 | 21 | ii. moral rights retained by the original author(s) and/or performer(s); 22 | 23 | iii. publicity and privacy rights pertaining to a person's image or likeness depicted in a Work; 24 | 25 | iv. rights protecting against unfair competition in regards to a Work, subject to the limitations in paragraph 4(a), below; 26 | 27 | v. rights protecting the extraction, dissemination, use and reuse of data in a Work; 28 | 29 | vi. database rights (such as those arising under Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, and under any national implementation thereof, including any amended or successor version of such directive); and 30 | 31 | vii. other similar, equivalent or corresponding rights throughout the world based on applicable law or treaty, and any national implementations thereof. 32 | 33 | 2. __Waiver.__ To the greatest extent permitted by, but not in contravention of, applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and unconditionally waives, abandons, and surrenders all of Affirmer's Copyright and Related Rights and associated claims and causes of action, whether now known or unknown (including existing as well as future claims and causes of action), in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each member of the public at large and to the detriment of Affirmer's heirs and successors, fully intending that such Waiver shall not be subject to revocation, rescission, cancellation, termination, or any other legal or equitable action to disrupt the quiet enjoyment of the Work by the public as contemplated by Affirmer's express Statement of Purpose. 34 | 35 | 3. __Public License Fallback.__ Should any part of the Waiver for any reason be judged legally invalid or ineffective under applicable law, then the Waiver shall be preserved to the maximum extent permitted taking into account Affirmer's express Statement of Purpose. In addition, to the extent the Waiver is so judged Affirmer hereby grants to each affected person a royalty-free, non transferable, non sublicensable, non exclusive, irrevocable and unconditional license to exercise Affirmer's Copyright and Related Rights in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "License"). The License shall be deemed effective as of the date CC0 was applied by Affirmer to the Work. Should any part of the License for any reason be judged legally invalid or ineffective under applicable law, such partial invalidity or ineffectiveness shall not invalidate the remainder of the License, and in such case Affirmer hereby affirms that he or she will not (i) exercise any of his or her remaining Copyright and Related Rights in the Work or (ii) assert any associated claims and causes of action with respect to the Work, in either case contrary to Affirmer's express Statement of Purpose. 36 | 37 | 4. __Limitations and Disclaimers.__ 38 | 39 | a. No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document. 40 | 41 | b. Affirmer offers the Work as-is and makes no representations or warranties of any kind concerning the Work, express, implied, statutory or otherwise, including without limitation warranties of title, merchantability, fitness for a particular purpose, non infringement, or the absence of latent or other defects, accuracy, or the present or absence of errors, whether or not discoverable, all to the greatest extent permissible under applicable law. 42 | 43 | c. Affirmer disclaims responsibility for clearing rights of other persons that may apply to the Work or any use thereof, including without limitation any person's Copyright and Related Rights in the Work. Further, Affirmer disclaims responsibility for obtaining any necessary consents, permissions or other rights required for any use of the Work. 44 | 45 | d. Affirmer understands and acknowledges that Creative Commons is not a party to this document and has no duty or obligation with respect to this CC0 or use of the Work. 46 | -------------------------------------------------------------------------------- /License-considerations.md: -------------------------------------------------------------------------------- 1 | # Licensing considerations for your F/OSS Fortran project 2 | > Please see [issue #9](https://github.com/Fortran-FOSS-Programmers/Best_Practices/issues/8 for a discussion, 3 | and work from that discussion to populate this document 4 | 5 | Please note that 6 | there is no "one-size-fits-all" software license, and picking an appropriate license is a personal choice. 7 | The license chosen will have impacts (both theoretical, and practical) on how the software is used, how it 8 | can be used, and by whom. Recommending specific licenses is beyond the scope of this document, and we will 9 | abstain from doing so. *We will strive to be as unbiased and factual as possible in discussing different 10 | licensing options*. 11 | 12 | ## Licensing resources 13 | Choosing an appropriate license for your Free/Open Source Software can be a daunting process. Here are some 14 | resources to help get you up to speed on commonly used licenses, and how to use them. 15 | 16 | - [Why you should use a BSD license](http://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html) 17 | - http://choosealicense.com 18 | - http://tldrlegal.com 19 | - [Comparison of FOSS licenses](https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses) 20 | - [GNU list of free licenses](http://www.gnu.org/licenses/license-list.html) 21 | - [GNU license selection advice](http://www.gnu.org/licenses/license-recommendations.html) 22 | 23 | > I'm trying to get rid of the formatting glitch above. I may have to clone and edit locally... please fix if you know how 24 | 25 | ## Licensing code snippets and project documents and documentation 26 | The source code of a software project should be licensed using a license appropriate to the specific needs of 27 | the project and project authors. Often, however, these licenses might not be appropriate for other documents 28 | included in the project, such as: 29 | 30 | - Project documentation 31 | - Project artwork 32 | - Other non-software project assets 33 | 34 | In addition, these documents and assets may include code snippets, which themselves may need to be released under 35 | an additional (usually more permissive) license. 36 | 37 | > continue discussion about licensing this stuff 38 | 39 | > Add subsections discussing licenses like CC for documentation, artwork, and code snippets 40 | 41 | ## Differences and considerations when choosing the main software license 42 | 43 | > Discuss general considerations here 44 | 45 | > Discuss particular licenses in their own subsections here 46 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Best practices and styles guidelines of Fortran FOSS Programmers 2 | 3 | > an opinionated list of *best practices* to be a good Fortran FOSS Programmer 4 | 5 | + [standard compliance](#standardization) counts... but *practicality* counts more; 6 | + [beautiful](#beautiful) is better than *ugly*: 7 | + [naming convention](#naming) counts; 8 | + [explicit](#explicit) is better than *impl.*; 9 | + [simple](#simple) is better than *CoMpleX*: 10 | + [structured](#structured) is better than *unStRUcturED*; 11 | 12 | --- 13 | 14 | [Guide](#guide) | [Motivations](#motivations) | [References](#references) | [Copyrights](#copyrights) 15 | 16 | --- 17 | 18 | # Guide to the document 19 | 20 | Before reading this document, please understand the following conventions. 21 | 22 | ## General rules 23 | 24 | General rules are emphasized by *blockquotes*, e.g. 25 | 26 | > be standards compliant as much as possible 27 | 28 | ## Examples 29 | 30 | In order to clearly explain our motivations we often report examples, both *positive* and *negative*. The examples snippets are syntax-highlighted and *decorated*, e.g. 31 | 32 | :x: 33 | ```fortran 34 | type foo 35 | contains 36 | procedure :: negate_foo 37 | generic :: operator(.not_foo.) => negate_foo ! .not_foo. is not a valid name 38 | end type 39 | ``` 40 | 41 | :white_check_mark: 42 | ```fortran 43 | type foo 44 | contains 45 | procedure :: negate_foo 46 | generic :: operator(.notFoo.) => negate_foo ! .notFoo. is a valid name 47 | end type 48 | ``` 49 | 50 | ## Compilers support 51 | 52 | Not all *best practices* are supported by all compilers, e.g. if a suggested practice relies on a modern Fortran standard it is likely that few compilers support it. When it is useful, the compilers support is emphasized by a check list like 53 | 54 | | Compiler | Version | Support | 55 | |----------------|---------|---------------------------| 56 | | GNU gfortran | 5.3+ | :heavy_check_mark: | 57 | | Intel Fortran | 15.03 | :heavy_exclamation_mark: | 58 | | IBM XL Fortran | 14.1 | :question: | 59 | 60 | --- 61 | 62 | # Motivations 63 | 64 | ## standard compliance counts... but practicality counts more 65 | 66 | Standards conformance should be considered of paramount relevance: 67 | 68 | > be standards compliant as much as possible 69 | 70 | However, follow this guideline with *counsciousness*, be ready to be *flexible*, many are the reasons why you could prefer to break the standard compliance. **Practicality** imposes a compromise generating a *hierarchy* of standards conformities: 71 | 72 | > + be standards compliant as much as possible... 73 | > + except when practicality needs extensions: 74 | > + prefer extensions that are widely supported by different (possible free) compilers. 75 | 76 | Among the common reasons to break standards compliance, the following are worth to be mentioned 77 | 78 | + exploit parallel architectures: Fortran is widely used in High Performance Computing (HPC) where parallel hardware is omnipresent; it is very common the necessity to adopt *third party solution* (generally a library) to exploit such a hardware; rather than a very *promising*, but uncommon solutions, prefer: [OpenMP](), [OpenACC](), ... 79 | + *consume third party library*: some problems thst are not strictly related to mathematical computations (e.g. OS-level operations or runtime errors handling) are often solved using mixed-languages, non standard libraries (typycaly C based, but Python is also commonn nowadays); in such a case consider exploiting `ISO_C_BINDING` to develop standards compliance codes as much as possible. 80 | 81 | TODO: Complete discussion of 'exploit parallel architectures' (first bullet point) 82 | 83 | Finally, be conscious that there are other (subtle) aspects that could make your code non-standard: for example, the use of *preprocessor* directives makes your code not strictly standard since there is no standard Fortran preprocessor. While many Fortraners use the `fpp` preprocessor which ships with Intel's Fortran compiler, others use the COCO preprocessor[[e]](#nagle-2012), and many use no preprocessor at all. 84 | 85 | ## Beautiful is better than *ugly* 86 | There is a common misconception about computer codes: *only the results count, no matter the form* of your code. This is wrong from many points of view, but mostly remember that: 87 | 88 | > in addition to writing code for the computer, you are also writing code for humans, yourself included. The purpose of the calculations and the methods used to do so must be clear 89 | 90 | see [[1](#modern-fortran-style)]. This means that results count, but also *readability* is a value: a readable and clear (and possible concise) code can be easily debugged, improved and *maintained* (e.g. ported on new architecture). As a consequence, the time you spend on beautify your code is not wasted: it will reduce future works, it will allow easy collaboration with new developers, it will make easy to evolve the code itself. 91 | 92 | In the case of code used in high-reliability environments (i.e. nuclear safety), source code may be subject to audits and peer review for *verification* purposes (i.e. ensuring the code correctly implements its functional specifications). Code which is obscure is difficult to review and verify and may harbor faults which testing does not reveal. 93 | 94 | The followings are some guidelines to try to develop *beautiful* (in the sense of readable/clear) codes: 95 | 96 | + [naming convention](#naming) counts; 97 | + [explicit](#explicit) is better than *impl.*; 98 | 99 | ### Naming convention counts 100 | The naming convention is a very personal choice. The following suggestions should be considered as they are... just *suggestions*. 101 | 102 | > + adopt your *opinionated* naming convention and use it **consistently**; 103 | > + prefer lowercase: Fortran is a case-insensitive language, thus you cannot rely on lower-UPPER case distinction for syntax checks; however, `CamelCase` style could help code readability, thus select your way: 104 | > + if you use a strict lowercase style, consider to exploit *underscores* (`lower_case`) to improve your names clearness (especially for multi-word names); 105 | > + try to use underscores consistently. For example, if the variables `temp_wall` and `temp-gas` have been defined, the floor temperature should be named `temp_floor`, not `tempfloor` or `floor_temp`. 106 | > + names should be *descriptive*, names should have *meaning*: do not strive too much in *local shortening*, adopt names that are *auto-explicative*; in particular, singular character names should be admissible for **only** index/counter variables; 107 | > + avoid *magic numbers*, use *parameters*, i.e. named constants; 108 | > + logical variables should be named to reflect the state they are used to conveying, e.g. 109 | > + prefer `lib_is_initialized` vs `lib_init`; 110 | > + prefer `obj_has_parent` vs `obj_parent`; 111 | > + take care of *entities disambiguation*; often you would have the same name for different entities, e.g. a module name and the name of the *main public derived type* it defines. 112 | > + the name of source files should reflect the name of the main entity they are defining; 113 | 114 | Note that there is at least one case where *underscores* style cannot be used, i.e. naming *defined operators*, e.g. 115 | 116 | :x: 117 | ```fortran 118 | type foo 119 | contains 120 | procedure :: negate_foo 121 | generic :: operator(.not_foo.) => negate_foo ! .not_foo. is not a valid name 122 | end type 123 | ``` 124 | In such a case, consider to exploit `CamelCase` style, e.g. 125 | 126 | :white_check_mark: 127 | ```fortran 128 | type foo 129 | contains 130 | procedure :: negate_foo 131 | generic :: operator(.notFoo.) => negate_foo ! .notFoo. is a valid name 132 | end type 133 | ``` 134 | 135 | #### General considerations 136 | The following general considerations are **not** *rule of thumb*, but they provide interesting details on some common scenario. 137 | 138 | + [Names readability](#names-readability) 139 | + [Names meaning](#names-meaning) 140 | + [Entities disambiguation](#entities-disambiguation) 141 | + [Procedures disambiguation](#procedures-disambiguation) 142 | 143 | TODO: Add more considerations. 144 | 145 | ##### Names readability 146 | The following are some interesting *suggestions* to improve readability. Some of them could be considered *anachronistic*: 147 | 148 | + write Fortran keywords in all *UPPERCASE*: this guideline was often adopted (in the near past) to distinguish reserved Fortran keywords from user's defined names; presently, almost all widely used editors provide a fairly complete syntax highlighting support by means of which the Fortran keywords are immediately distinguished form others; as a consequence, before adopt this style, consider to exploit editors highlighting thus saving your *typing efforts* necessary to capitalized all Fortran keywords; 149 | + exception could be the naming of *global accessible* variables (that, indeed should be avoided if they are not parameters): all *UPPERCASE* names could help to distinguish global scope entities (e.g. module or program variables) from local ones (e.g. procedures variables) 150 | 151 | :white_check_mark: 152 | ```fortran 153 | module global_scope 154 | integer :: GLOBAL 155 | contains 156 | subroutine unsafe(is_local, local_global) 157 | logical, intent(in) :: is_local 158 | integer, intent(out) :: local_global 159 | 160 | local_global = 0 161 | if (.not.is_local) local_global = GLOBAL 162 | return 163 | end subroutine unsafe 164 | end module global_scope 165 | ``` 166 | + avoid naming variables with single-character `l`, i.e. lower case `L`: often the lower case name `l` can be confused with the number constant `1`, especially when some mono-spaced/sans-serif fonts are used, e.g. in the statement `do l=1, N` do you easily distinguish the loop counter from the loop starting value? Again, syntax highlighting sometimes helps to distinguish variables from numeric constants; note that similar considerations could be made also for the single-character name `O`, i.e. upper case `o` that could be confused with the number constant `0`; 167 | 168 | ##### Names meaning 169 | As a *rule of thumb* (yes, we aforementioned that these are not rule of thumb...) consider that 170 | 171 | > all names must have a meaning. 172 | 173 | Current (modern) Fortran standards (F90 and later) allow *long* names (up to 63 characters). Consider exploiting all the characters you need, do not strive too much on *local shortening*. 174 | 175 | Let us consider the definition of the air *speed of sound*: naming it as `a`, as it is common in some fields, is not a good choice, it being unclear for who is not familiar with this implicit convention; even worst could be to name it as `sos` for the sake of conciseness: does this variable contain the value of the speed of sound or a help request? A name like `speed_of_sound` is preferable since it is clear and of reasonable length. 176 | 177 | If the speed of sound for multiple materials is needed, consider using an array with named constants representing the index for material, i.e. `speed_of_sound(AIR)`, `speed_of_sound(WATER)`, etc. 178 | 179 | Verbosity or names-lengthy could be effectively limited with other helper constructs when/where conciseness helps readability. Let us assume that our speed of sound variable is a member of a derived type representing a gas 180 | 181 | :white_check_mark: 182 | ```fortran 183 | type :: gas 184 | real :: gamma = 0.0 185 | real :: pressure = 0.0 186 | real :: speed_of_sound = 0.0 187 | end type gas 188 | ``` 189 | 190 | Local names shortening could be easily achieved exploiting the `associate` construct, e.g. 191 | 192 | :white_check_mark: 193 | ```fortran 194 | function density(low_pressure_gas) 195 | type(gas), intent(in) :: low_pressure_gas 196 | real :: density 197 | 198 | associate(gamma => low_pressure_gas%gamma, & 199 | pressure => low_pressure_gas%pressure, & 200 | speed_of_sound => low_pressure_gas%speed_of_sound) 201 | density = gamma * pressure / (speed_of_sound**2) 202 | end associate 203 | return 204 | end function density 205 | ``` 206 | 207 | NOTE: As of Fortran 2008, `gamma` is an intrinsic math function; a different variable name should be used to represent the isentropic expansion coefficient (ratio of heat capacities). This illustrates both the importance and (at times) difficulty of choosing good names for variables. 208 | 209 | Consider exploiting *meaningful names* to their *extreme*. Let us assume we are developing a large library that must deal with numerous *objects*, and we need to perform the same set of *actions* on these data, i.e. we need to develop a set of procedures performing the *same conceptual* action, but on different objects. In order to improve the readability of this large library, it could be helpful to provide to such a procedures set with a *complete meaningful and descriptive* name, e.g. 210 | 211 | :white_check_mark: 212 | ```fortran 213 | subroutine compute_transpose_of_sparse_approximate_matrix(...) 214 | ... 215 | subroutine compute_transpose_of_dense_approximate_matrix(...) 216 | ... 217 | subroutine compute_transpose_of_sparse_exact_matrix(...) 218 | ... 219 | ``` 220 | 221 | | Compiler | Version | Support | 222 | |----------|---------|---------------------------| 223 | | all | all | :heavy_check_mark: | 224 | 225 | ##### Entities disambiguation 226 | It could happen that you would like to attribute the same name to different *entities* in the same *scope*. An emblematic example is the definition of a derived type. Typically, for important *classes*, a derived type is defined into its own module. Consequently, you have to select a name (with a meaning) for both the module and the derived type. You could be tempted to write something like 227 | 228 | :x: 229 | ```fortran 230 | module shape_sphere 231 | type, public :: shape_sphere ! not allowed 232 | end type shape_sphere 233 | end module shape_sphere 234 | ``` 235 | This is not allowed because two different *entities*, namely the module and the derived type, have the same name in the same scope. In such a situation, you should consider adopting a convention to disambiguate names. Note that a similar ambiguity happens when you would like to name a variable with the same of its type, e.g.: 236 | 237 | :x: 238 | ```fortran 239 | type(shape_sphere) :: shape_sphere ! not allowed 240 | ``` 241 | 242 | Among the others, the following are widely-used disambiguation techniques: 243 | 244 | ###### use *prefix* and or *suffix* 245 | + suffix modules with `_m` and derived type with `_t`: 246 | 247 | :white_check_mark: 248 | ```fortran 249 | module shape_sphere_m 250 | type, public :: shape_sphere_t 251 | end type shape_sphere_t 252 | end module shape_sphere_m 253 | ``` 254 | + prefix *all* modules building up a library (or a package) with a common tag, e.g. `pkg_`: 255 | 256 | :white_check_mark: 257 | ```fortran 258 | module pkg_shape_sphere 259 | type, public :: shape_sphere 260 | end type shape_sphere 261 | end module pkg_shape_sphere 262 | ``` 263 | 264 | ###### use different styles concurrently 265 | Use mixed mode `CamelCase/under_score` style, one for entity: 266 | 267 | :white_check_mark: 268 | ```fortran 269 | module shape_sphere ! underscores for module name 270 | type, public :: ShapeSphere ! CamelCase for derive type 271 | end type ShapeSphere 272 | end module shape_sphere 273 | ``` 274 | 275 | **Please note:** This style doesn't work in case you have module and/or type names that only consist of a single word. `Car` and `car` are the same thing to Fortran compilers, so it will generate namespace conflicts. 276 | 277 | ###### exploit submodules (specific for module/derived type disambiguation) 278 | exploit the (new) `submodule` construct to separate the API definition of the derived type and its actual implementation and, consequently, to distinguish the module name from the derived type being defined, e.g.: 279 | 280 | :white_check_mark: 281 | ```fortran 282 | module speaker_interface 283 | type :: speaker 284 | contains 285 | procedure, nopass :: speak 286 | end type speaker 287 | 288 | interface 289 | module subroutine speak 290 | end subroutine speak 291 | end interface 292 | end module 293 | 294 | submodule (speaker_interface) speaker_implementation 295 | contains 296 | subroutine speak 297 | print "(A)", "Hello, world!" 298 | end subroutine speak 299 | end submodule speaker_implementation 300 | ``` 301 | Here `_interface` suffix is used to distinguish the API interface definition of the module from its actual implementation done into the submodule suffixed by `_implementation`, the derived type `speaker` being disambiguated at well. 302 | 303 | | Compiler | Version | Support | 304 | |----------------|---------|-------------| 305 | | GNU gfortran | 5.3+ | :question: | 306 | | Intel Fortran | 15.03 | :question: | 307 | | IBM XL Fortran | 14.1 | :question: | 308 | 309 | ##### Procedures disambiguation 310 | The disambiguation and readability improvement of procedures naming merit some specific considerations: 311 | 312 | > + insert an explicit reference to the class name into each type bound procedure name, e.g. 313 | 314 | :white_check_mark: 315 | ```fortran 316 | type :: object 317 | contains 318 | procedure :: stuff_1 => perform_stuff_1_on_object 319 | procedure :: stuff_2 => perform_stuff_2_on_object 320 | ... 321 | end type object 322 | ``` 323 | this allow you to easy move the object and its implementation into other modules preserving namespaces integrity. 324 | > + adopt mixed style `CamelCase/under_score` to identify procedures with respect other entities, e.g. 325 | 326 | :white_check_mark: 327 | ```fortran 328 | type :: gas 329 | real :: speed_of_sound ! underscores style for variables 330 | contains 331 | procedure :: ProjectOnCharacteristics ! CamelCase for procedures 332 | end type gas 333 | ``` 334 | > + procedures should have an *an action **verb*** into their name ... 335 | > + however, consider to distinguish `subroutine` from `function` exploiting the presence (or the absence) of the action verb, i.e. use **verb form** for subroutine and **noun form** for function, e.g. 336 | 337 | :white_check_mark: 338 | ```fortran 339 | ! verb form 340 | subroutine get_useful_thing 341 | end subroutine get_useful_thing 342 | ! noun form 343 | function useful_thing 344 | end function useful_thing 345 | ``` 346 | 347 | Go to [TOP](#top) or [Up](#beautiful) 348 | 349 | ### Explicit is better than *impl.* 350 | Implicit typing can *speed* the development of codes, but it is difficult to debug/read/understand **implicit-defined** codes, thus 351 | 352 | > always exploit `implicit none` statement: 353 | + into *hosts*: place `implicit none` at the start of each `program`, `module` and `submodule`; 354 | + into procedures that are not contained into a *host*: place `implicit none` at the start of each `function` and `subroutine` defined outside a host; 355 | 356 | A sane explicit style is 357 | 358 | :white_check_mark: 359 | ```fortran 360 | module sane_interface 361 | implicit none 362 | type sane_type 363 | contains 364 | procedure, nopass :: print_hello 365 | end type sane_type 366 | end module sane_interface 367 | 368 | submodule (sane_inteface) sane_implementation 369 | implicit none 370 | contains 371 | subroutine print_hello 372 | print "(A)", "Hello, world!" 373 | end subroutine print_hello 374 | end submodule sane_implementation 375 | 376 | program sane 377 | use sane_interface 378 | implicit none 379 | type(sane_type) :: greeter 380 | call greeter%print_hello 381 | end program sane 382 | ``` 383 | Note that is not necessary to add `implicit none` into the subroutine `print_hello` because it inherits the clause from its host, namely the submodule `sane_implementation`. 384 | 385 | It is also worth to mention that many compilers offer the possibility to enforce `implicit none` everywhere by means of dedicated options, e.g. GNU gfortran offers the option `-fimplicit-none`. 386 | 387 | #### Unusual implicit typing usage 388 | There are particular scenarios where implicit typing could be admissible. 389 | 390 | ##### Implicit templating 391 | Exploiting implicit typing and standard `include` statement could be used to *mimic* templating programming 392 | 393 | :white_check_mark: 394 | ```fortran 395 | subroutine abc_sub 396 | implicit type(abc) (v) 397 | include "sub_base-inc.f90" 398 | end subroutine abc_sub 399 | ``` 400 | where `sub_base-inc.f90` contains just the usage of variable `var`. 401 | 402 | Go to [TOP](#top) or [Up](#explicit) 403 | 404 | ### Simple is better than *CoMpleX* 405 | 406 | *Simplicity* is a fundamental key to writing readable and maintainable code. In general, a *task* can be completed by means of different approaches: depending on the particular application, different approaches result in simple or complex codes. In this regard, different programming *idioms* should be used for different aims, e.g. Object Oriented Programming is tailored to improve code maintainability and reausability for complex (possible *generic*) tasks, but it could add unnecessary complexity for simple applications. 407 | 408 | Concerning simplicity, some aspects should be considered: 409 | + [structured](#structured) is better than *unStRUcturED*; 410 | 411 | #### Structured is better than *unStRUcturED* 412 | 413 | Commonly, a code could be viewed as sequence of statements that *flow* from one statement to the next one, but to allow the program to behave differently in response to different inputs, *jump* statements are often used, making the flow of control generally non-linear. Such flows can be distingushed in **structured** and **unstructured** (in the worst case leading to so called *spaghetti-code*): 414 | 415 | + structured flows are easy to read/improve/maintain because the jump conditions must strictly respect a *location constraint* allowing the flow to jump into only one prescribed location; 416 | + unstructured flows are more difficult to follow and thus more difficult to read/improve/maintain because the jump conditions are totally unrestricted allowing the flow to jump anywhere; 417 | 418 | While the former is less flexible but more readable the latter may allow very efficient code which is very complex and unreadable. In Fortran, many constructs allow for structured flow, primarily `call/return`, `do/end do`, `exit`, `cycle` and the branching constructs like `select case` or `if elseif`. On the contrary, the most famous unstructured jump statement is `goto` (*unconditional*, *computed*, or *assigned*, or the related *arithmetic IF* statement) that allows flow jump to any labelled position (upward or downward) within a program unit. 419 | 420 | > it is recommended to avoid, as much as possible, `goto` statement: 421 | + in almost all cases goto can be replaced by means of structured-safe constructs **without** any performance penalty while greatly improving readability and maintainability; 422 | + but exceptions should be allowed for very corner cases that, anyhow, should be in the hands of experts. 423 | 424 | As a matter of fact, for very special cases, `goto` could be very helpful, see [[a]](#dijkstra-1968)[[b]](#rubin-1987). Commonly, such applications involves very low-level tasks that are more likely happening in C contest rather Fortran one, e.g. exceptions (errors) handling, resources cleaner/finalizer, ecc... The interested readers could read a recent study of Nagappan et. al. [[c]](#nagappan-2015) showing that `goto` is still used on many GitHub-hosted projects. Moreover, `goto` seems to be extensively used in the Linux kernel, e.g. see [[d]](#wilkens-2003). 425 | 426 | > `goto` is not the evil *per se*, rather because it likely drives [programmers] to develop unstructured code that flows chaotically as the flight of a *butterfly*. 427 | 428 | ##### Examples 429 | 430 | Fortran is a very high-level language, we *discourage* the usage of `goto`, but this is not a *rule of thumb*. The following examples show some cases where `goto` is commonly used and how to avoid it. 431 | 432 | ###### Exception/error handling 433 | 434 | Sometimes, the *algorithm* must take into account the occurences of exceptions or errors and, for example, break a (series) of loop. In the old-good-days, such an exceptions handling was done by means of `goto`: 435 | 436 | :x: 437 | ```fortran 438 | do a=1,n 439 | do b=1,m 440 | ! do some stuff ... 441 | if (is_error_occurred) goto 10 ! break out of the outer loop 442 | ! ... 443 | end do 444 | end do 445 | 10 continue 446 | ``` 447 | 448 | Although the above code is clear, for large loops it soon becomes *obscure*: the *jump* condition `goto 10` is not actually telling more than *jump on label 10*, but `label 10` can be anywhere in the current scope, even before the start of the outer loop. The resulting flow is *unstructered* and could lead to *spaghetti* code if not carefully handled. On the contrary, we suggest using **named** do loops: 449 | 450 | :white_check_mark: 451 | ```fortran 452 | a_loop : do a=1,n 453 | b_loop: do b=1,m 454 | !do some stuff ... 455 | if (done) exit a_loop ! break out of the outer loop 456 | !... 457 | end do b_loop 458 | end do a_loop 459 | ``` 460 | The `exit` statement is more clear, it is jumping outside (to the end) of the outer (named) loop, that is a structured flow: exit can jump only foreward. 461 | 462 | Similarly, there are conditions when one wants to skip to the end of the loop body and advance to the next iteration. The classic method of handling this case is also with a `goto`: 463 | 464 | :x: 465 | ```fortran 466 | do a=1,n 467 | ! do some stuff ... 468 | if (condition_detected) goto 10 ! skip remainder of loop body 469 | ! do a lot of other things 470 | x(a) = 0.0 471 | 10 continue 472 | end do 473 | ``` 474 | 475 | The code is clear in this toy example but again, consider code with a complex loop body. Or worse, code structure such as the following: 476 | 477 | :x: 478 | ```fortran 479 | ! This is occasionally seen in FORTRAN 77 code 480 | do 10 a=1,n 481 | ! do some stuff ... 482 | if (condition_detected) goto 10 ! skip remainder of loop body 483 | ! do a lot of other things 484 | x(a) = 0.0 485 | 10 continue ! Please don't do this 486 | ``` 487 | 488 | or 489 | 490 | :x: 491 | ```fortran 492 | ! This is seen more often in FORTRAN IV and FORTRAN 66 code 493 | do 10 a=1,n 494 | ! do some stuff ... 495 | if (condition_detected) goto 10 ! skip remainder of loop body 496 | ! do a lot of other things 497 | 10 x(a) = 0.0 ! Please, please, PLEASE don't do this 498 | ``` 499 | 500 | The intent of the `goto` and behavior of the code can be badly obscured. Using both the `cycle` statement and named loops, the code can be greatly clearified: 501 | 502 | :white_check_mark: 503 | ```fortran 504 | a_loop: do a=1,n 505 | ! do some stuff ... 506 | if (condition_detected) cycle a_loop ! skip remainder of loop body 507 | ! do a lot of other things 508 | x(a) = 0.0 509 | end do a_loop 510 | ``` 511 | 512 | Here it is clear that the loop `a_loop` is *short-circuited*; the intent is to skip the remainder of the loop body and advance to the next iteration of the loop. If `cycle` occurs on the last iteration of the loop, the loop terminates. 513 | 514 | ###### Alternate conditional branches 515 | 516 | The *arithmetic IF* statement is an obsolete control structure which was used to implement alternate branches before the `if/elseif/else` construct was added to the Fortran standard. 517 | 518 | :x: 519 | ```fortran 520 | ! This is seen often in FORTRAN IV and FORTRAN 66 code 521 | if (j) 10, 20, 30 522 | 10 ! Do things if j < 0 523 | goto 40 524 | 20 ! Do things if j == 0 525 | goto 40 526 | 30 ! Do things if j > 0 527 | 40 continue 528 | ``` 529 | 530 | The logic of this example is clear however when branching logic becomes complex and nested and the labels references in the arithmetic `IF` statement are scattered throughout the code, the code quickly becomes unreadable and unmaintainable. 531 | 532 | :white_check_mark: 533 | ```fortran 534 | if (j > 0) then 535 | ! Do things if j < 0 536 | elseif (j == 0) then 537 | ! Do things if j == 0 538 | else 539 | ! Do things if j > 0 540 | end if 541 | ``` 542 | 543 | ###### Resources cleaner/finalizer 544 | 545 | Often, the *algoritm* allocates resouces that need to be *cleaned/finalized* when the task is finished and, in general, resources are *case-dependent* thus different *kind* of cleaners are necessary. 546 | 547 | TODO: Document finalization best practices 548 | 549 | ##### References 550 | 551 | [[a]]() *Go To Statement Considered Harmful*, Edsger W. Dijkstra, ACM, Vol. 11, No. 3, March 1968, pp. 147-148. 552 | 553 | [[b]]() *GOTO Considered Harmful*, Frank Rubin, ACM, Vol. 30, No. 3, March 1987, pp. 195-196. 554 | 555 | [[c]](http://www.se.rit.edu/~mei/publications/pdfs/An-Empirical-Study-of-Goto-in-C-Code-from-GitHub-Repositories.pdf) *An Empirical Study of Goto in C Code from GitHub Repositories*, M. Nagappan, et. al, Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering, Pages 404-414, 2015. 556 | 557 | [[d]](http://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/) *USING GOTO IN LINUX KERNEL CODE*, R. Wilkens, *epistolary* discussion with Linus Torvalds, 2003. 558 | 559 | [[e]](http://www.daniellnagle.com/coco.html) *Fortran Program coco*, D. Nagle, 2012. 560 | 561 | Go to [TOP](#top) or [Simple](#simple) 562 | 563 | ### References 564 | 565 | Sources of inspiration: 566 | 567 | [[1]]() [Modern Fortran: Style and Usage](http://www.amazon.com/Modern-Fortran-Norman-S-Clerman/dp/052173052X), *Norman S. Clerman and Walter Spector*. 568 | 569 | Go to [TOP](#top) 570 | 571 | ### Copyrights 572 | 573 | This document is released under a Creative Commons Attribution-ShareAlike 4.0 International [License](https://github.com/Fortran-FOSS-Programmers/Best_Practices/blob/master/LICENSE-CC-by-sa.md). 574 | 575 | All the code-snippets contained into this document are released under a Creative Commons CC0 1.0 Universal [License](https://github.com/Fortran-FOSS-Programmers/Best_Practices/blob/master/LICENSE-CC0.md). 576 | 577 | Go to [TOP](#top) 578 | --------------------------------------------------------------------------------