Coding style refers to stylistic choices that do not effect how a code runs. They are not syntactical, but instead are mostly about making code easier to read. Large coding projects always have an official style because if many different people were all contributing code in different styles then it would be really difficult for anyone to read. While style choices are mostly arbitrary, many are based on experience of what leads to more readable code.  The python standard library follows a style called PEP8 and much of python code also follows something close to this style. Here is a cheatsheet with some highlights.

Linters

Style choices and other issues that don’t stop code from running, but when they build up can cause code to be difficult to understand are called lint. And fixing them is called linting. The easiest way to lint some code is to use code to check for these issues, a linter. There are a number of different packages that exist to do this: pycodestyle, pydocstyle, flake8, pylint. Running any of these will give you a list or issues with your code. They can all be installed with conda or pip and  be configured to follow different rules or ignore certain issues to allow you to check only what you find important.  For a more detailed overview look here.

Doc Strings

One style element are called doc strings, they are style for commenting your code. One advantage of them is that if you stick to the style there are tools that will automatically generate documentation for your code. Also, they can be accessed using the help() function. That’s pretty cool. pydocstyle will check the style of your docstrings as will tools like pylint. Here is an example of the numpy docstring style. Look here for more on this topic.