<commit_before>Conventions
===========

This document contains conventions to be followed when contributing to
Export Layers.

* [Coding Conventions](#Coding-Conventions)
* [Writing Commit Messages](#Writing-Commit-Messages)


Glossary
--------

Element = module, class, function or variable


Coding Conventions <a name="Coding-Conventions"></a>
------------------

Use PEP8 and PyLint to enforce coding conventions with their respective
configuration files:
* [PEP8 for PyDev](PyDev/org.python.pydev.analysis.yaml)
* [PyLint](PyLint/pylintrc)

Additional conventions that override or complement the conventions in the
aforementioned utilities are specified below.


### Line length

Maximum line length is:
* 90 characters for code,
* 80 characters for docstrings and comments.


### Spacing

Use a separator (commented line containing "=" characters) for a block of
related functions or classes in a module.

Use two empty lines between a separator and a function or class definition. Use
one empty line between a separator and other statements.


### Indentation

Use 2 spaces for indentation.

Use hanging indents, with indented lines having 2 extra spaces.

For multi-line conditions, align expressions vertically.

For multi-line function and class definitions, loops and `with` statements, use
hanging indents and add 2 spaces after the beginning of the name of the
function/class, first loop variable or the expression after the `with` keyword.
For example:

    def __init__(
          self, name, default_value, display_name=None, description=None,
          error_messages=None):
      with open(
             "/totally/ridiculously/long/path/to/file.txt", "w") as f:
        pass


### Quotes in and Around Strings

Use double quotes everywhere except cases where single quotes or backquotes are
used.

Use single quotes:
* in element names in non-user messages (to be consistent with e.g. Python
  exception messages),
* in any string containing double quotes (to avoid inserting backslashes).

Use backquotes in element names in comments.


### Naming

Use the following conventions for terms and variables:

| Term             | Variable name | Meaning                               |
|------------------|---------------|---------------------------------------|
| File name        | `filename`    | File basename                         |
| File path        | `filepath`    | Absolute or relative file path        |
| Directory path   | `dirpath`     | Absolute or relative directory path   |


### Imports

Import modules at the beginning of a module.

Use explicit relative imports in modules not used as main modules. For modules
forming a library, this avoids a dependency on applications using the library.

Import whole modules, do not import individual classes, functions or other
objects. Exceptions:
* `from gimp import pdb`

Do not use wildcard imports. Exceptions:
* `from future.builtins import *` to help improve Python 3 compatibility.


### Executing Code

Do not execute code on the module or class level. Exceptions to this rule include:
* initializing variables or constants,
* initializing application configuration,
* initializing a package or a library,

Do not execute functions from the GIMP API or PDB on the module or class level
as they are not fully initialized yet and it causes the application to crash.

Do not call the `_` function to mark module- or class-level strings as
translatable. You need to defer the translation until the strings are used in<commit_msg>Conventions: Allow standalone scripts to run on module/class level<commit_after>Conventions
===========

This document contains conventions to be followed when contributing to
Export Layers.

* [Coding Conventions](#Coding-Conventions)
* [Writing Commit Messages](#Writing-Commit-Messages)


Glossary
--------

Element = module, class, function or variable


Coding Conventions <a name="Coding-Conventions"></a>
------------------

Use PEP8 and PyLint to enforce coding conventions with their respective
configuration files:
* [PEP8 for PyDev](PyDev/org.python.pydev.analysis.yaml)
* [PyLint](PyLint/pylintrc)

Additional conventions that override or complement the conventions in the
aforementioned utilities are specified below.


### Line length

Maximum line length is:
* 90 characters for code,
* 80 characters for docstrings and comments.


### Spacing

Use a separator (commented line containing "=" characters) for a block of
related functions or classes in a module.

Use two empty lines between a separator and a function or class definition. Use
one empty line between a separator and other statements.


### Indentation

Use 2 spaces for indentation.

Use hanging indents, with indented lines having 2 extra spaces.

For multi-line conditions, align expressions vertically.

For multi-line function and class definitions, loops and `with` statements, use
hanging indents and add 2 spaces after the beginning of the name of the
function/class, first loop variable or the expression after the `with` keyword.
For example:

    def __init__(
          self, name, default_value, display_name=None, description=None,
          error_messages=None):
      with open(
             "/totally/ridiculously/long/path/to/file.txt", "w") as f:
        pass


### Quotes in and Around Strings

Use double quotes everywhere except cases where single quotes or backquotes are
used.

Use single quotes:
* in element names in non-user messages (to be consistent with e.g. Python
  exception messages),
* in any string containing double quotes (to avoid inserting backslashes).

Use backquotes in element names in comments.


### Naming

Use the following conventions for terms and variables:

| Term             | Variable name | Meaning                               |
|------------------|---------------|---------------------------------------|
| File name        | `filename`    | File basename                         |
| File path        | `filepath`    | Absolute or relative file path        |
| Directory path   | `dirpath`     | Absolute or relative directory path   |


### Imports

Import modules at the beginning of a module.

Use explicit relative imports in modules not used as main modules. For modules
forming a library, this avoids a dependency on applications using the library.

Import whole modules, do not import individual classes, functions or other
objects. Exceptions:
* `from gimp import pdb`

Do not use wildcard imports. Exceptions:
* `from future.builtins import *` to help improve Python 3 compatibility.


### Executing Code

Do not execute code on the module or class level. Exceptions to this rule include:
* initializing variables or constants,
* initializing application configuration,
* initializing a package or a library,
* standalone scripts such as test runners, git hooks, etc.

Do not execute functions from the GIMP API or PDB on the module or class level
as they are not fully initialized yet and it causes the application to crash.

Do not call the `_` function to mark module- or class-level strings as
translatable. You need to defer the translation until the strings are used in
{'fraction_non_alphanumeric': 0.08749298934380258, 'fraction_numerical': 0.0028042624789680315, 'mean_word_length': 3.304767652383826, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1648215', 'n_tokens_mistral': 1814, 'n_tokens_neox': 1714, 'n_words': 878}