From dae8278f1c39eb61e7cdb28735562543ae2a48a6 Mon Sep 17 00:00:00 2001 From: Pietro Monticone <38562595+pitmonticone@users.noreply.github.com> Date: Sun, 21 May 2023 22:19:45 +0200 Subject: [PATCH] Update style.md --- docs/src/developer/style.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/src/developer/style.md b/docs/src/developer/style.md index b1d83cc39..b996aa1d9 100644 --- a/docs/src/developer/style.md +++ b/docs/src/developer/style.md @@ -8,7 +8,7 @@ Function additions should meeting the following criteria: - All functions should be clearly named, without abbreviations, and with underscores between words, _e.g._ `parse_file` or `constraint_bus_voltage_magnitude`; in Python this is known as [`lower_case_with_underscores`](https://legacy.python.org/dev/peps/pep-0008/#descriptive-naming-styles). The exception to the abbreviate rule is cases where abbreviations would be expected in the modeling of power systems. - All functions that are not prepended by an underscore `_` will be exported by default (_i.e._ when a user uses `using PowerModelsDistribution`). Public functions should have a detailed docstring instructing on usage -- All functions that modify data in place should end with an exclamation point `!` and the function input that is being modified should be the first argument (or first arguments in the case where multiple inputs are being modified in place). The exceptions to this rule are constraint and variable creation functions (_i.e._ those functions related to JuMP model creation), which do not include the exclaimation point +- All functions that modify data in place should end with an exclamation point `!` and the function input that is being modified should be the first argument (or first arguments in the case where multiple inputs are being modified in place). The exceptions to this rule are constraint and variable creation functions (_i.e._ those functions related to JuMP model creation), which do not include the exclamation point - All function arguments, including keyword arguments, should have their types specified. - Private functions, _i.e._ those intended to be for internal use only, should follow the same descriptive naming conventions as functions exported by default, and should always include docstrings to describe their purpose. - Functions should be separated by two blank lines @@ -30,7 +30,7 @@ When specifying types, _i.e._ when specifying the type of a function argument, o ## Constants -Whenever possible, `const` should be used to eliminate unnecesary re-evaluations of code, and every `const` should have a docstring, whether internal or public. +Whenever possible, `const` should be used to eliminate unnecessary re-evaluations of code, and every `const` should have a docstring, whether internal or public. ## JuMP Variables and Constraints