Code Formatting
Johnny Appleseed has been brought up-to-speed with the requirements for the "Open Potato" project that he has been assigned to. After downloading the tools in the SlashRoots Development Toolkit, he is now assigned to write a module that should allow for the tracking of prices for potatoes. SlashRoots primarily develops open-source projects and is therefore largely collaborative and requires adhering to standards that are widely adopted by the community. Before he starts writing his first line of code he needs to review the steps involved in properly formatting his code.
Proper formatting allows a team to easily maintain a code base, and in python it enforces variable and method scoping. There are also a number of automated document generators that can extract code documentation and display it for easy and quicker readability (example Swagger™ for python). https://helloreverb.com/developers/swagger
This section is based on the recommendations made by the Python team (Warsaw, Coghlan and vanRossum 2001).
Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged.
Since module names are mapped to file names, and some file systems are case insensitive and truncate long names, it is important that module names be chosen to be fairly short -- this won't be a problem on UNIX, but it may be a problem when the code is transported to older Mac or Windows versions, or DOS.
When an extension module written in C or C++ has an accompanying Python module that provides a higher level (e.g. more object oriented) interface, the C/C++ module has a leading underscore (e.g. _socket ).
Class names should normally use the CapWords convention.
The naming convention for functions may be used instead in cases where the interface is documented and used primarily as a callable.
Note that there is a separate convention for builtin names: most builtin names are single words (or two words run together), with the CapWords convention used only for exception names and builtin constants.
Function names should be lowercase, with words separated by underscores as necessary to improve readability. mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.
Use the function naming rules: lowercase with words separated by underscores as necessary to improve readability.
Use one leading underscore only for non-public methods and instance variables.
To avoid name clashes with subclasses, use two leading underscores to invoke Python's name mangling rules.
Python mangles these names with the class name: if class Foo has an attribute named __a , it cannot be accessed by Foo.__a . (An insistent user could still gain access by calling Foo._Foo__a .) Generally, double leading underscores should be used only to avoid name conflicts with attributes in classes designed to be subclassed.
Constants are usually defined on a module level and written in all capital letters with underscores separating words. Examples include MAX_OVERFLOW and TOTAL .
Utilize existing framework to operate faster and therefore smarter! Never reinvent the wheel – unless that’s the aim of your project! Some of the framework and packages used by SlashRoots:
DJango - https://www.djangoproject.com/
Password Policy Framwork - https://pypi.python.org/pypi/django-password-policies
Drupal - https://www.drupal.org/
