Create validate_transformer_code_style function

[csala]

A function should be implemented to automatically validate the code style of any new Transformer.

Function Name and Module

The function should be implemented inside tests/contributing.py and should be called validate_transformer_code_style

Inputs

The function should accept a single input:

• transformer (class or str): Transformer class or full Python name of the class (e.g. DatetimeTransformer or "rdt.transformers.time.DatetimeTransformer")

Outputs

The function should return a single bool value indicating whether the code style is correct or not.

Behavior

The function should run all the third party code style checkers (flake8, isort, pylint...) as well custom code analysis checks and report whether all of them pass, as well as feedback about why they do not otherwise.

List of Checks

The following validations must be performed and reported:

Check	Correct If	What does it check
flake8	flake8 check passes	PEP8 standards and basic static code analysis
isort	isort check passes	Imports are properly sorted
pylint	pylint check passes	Static code analysis and programming style
pydocstyle	pydocstyle check passes	Whether the docstrings are written in the right format
Transformer Name	The Transformer name is correct	Transformer name ends with Transformer (e.g. DatetimeTransformer)
Unit Tests Exist	The unit tests module exists and is located in the right place	The unit tests module should be located called tests/unit/transformers/<transformer_family>/<data_type>.py
Unit Test function names	The unit test function names are correct	The unit test function names should be called test_<method_name>_<test_case_name>

Prints to console

The function prints several messages on the console indicating:

• The path to the source file of the Transformer, which is being analyzed.
• A message indicating whether the code style is correct or not.
• A list of things that were validated and whether they were correct or not (list above).

Usage Examples

Success

External tool failure

Custom validation failure

[pvk-developer]

The current format of our docstrings follows the Google style guide, we can add pydocstyle and setting the convention to google.

However there is a bug in their library which produces D417 Missing arguments description, which we do have, and occurs all over our docstrings and we will have to ignore the D417 until this issue is fixed. Reference to the issue: PyCQA/pydocstyle#449

[pvk-developer]

Flake8 comes with a lot of different addons that we can use to adapt it to our codestyle and checking, here is a list of plugins that I found to be interesting for us:

Addons that already pass

• flake8-builtins - Check for python builtins being used as variables or parameters.
• flake8-comprehensions - Helps you write better list/set/dict comprehensions.
• flake8-debugger - Debug statement checker.
• flake8-variables-names - Extension that helps to make more readable variables names.
• Dlint - Tool for encouraging best coding practices and helping ensure Python code is secure.
• flake8-mock - Provides checking mock non-existent methods.
• flake8-fixme - Check for FIXME, TODO and other temporary developer notes.
• flake8-eradicate - Plugin to find commented out or dead code.
• flake8-mutable - Extension for mutable default arguments.
• flake8-print - Check for print statements in python files.

Addons that we want to add but require changes to our code

• flake8-pytest-style - Plugin checking common style issues or inconsistencies.
• flake8-quotes - Extension for checking quotes in python.
• flake8-use-fstring - Jump-start into modern Python by forcing yourself to use f-strings.
• flake8-multiline-containers - Plugin to ensure a consistent format for multiline containers.
• pandas-vet - Plugin that provides opinionated linting for pandas code.
• pep8-naming - Check the PEP-8 naming conventions.
• flake8-expression-complexity - Plugin to validate expressions complexity.

[csala]

• flake8-use-fstring - Jump-start into modern Python by forcing yourself to use f-strings.

This may overlap with the flake8-sfs functionality. If this one works fine and we already adapted the code to it, flake8-sfs and the corresponding ignores in setup.cfg can be removed too.

[csala]

@pvk-developer by looking at your PR it seems like some of these plugins do not require us to change anything in our code, but some others do.
I suggest that we separate this in several PRs:

• 1 PR for all the plugins that do not introduce any changes, which can be quickly validated and merged
• 1 PR for each new plugin that introduces changes, so we can validate whether we agree on the changes suggested by the plugin or not. I suggest to avoid stacking the PRs and point all of them directly to v0.6.0-dev, so we do not need to care about the order in which they are merged.