Components
MODULES
Modules should be installed via pip, including modules from github. To install modules from github the following article describes the steps involved.
Structure
projectx |-- app1 | |-- __init__.py | |-- models.py | |-- views.py |-- app2 | |-- __init__.py | |-- models.py | '-- views.py |-- appx | |-- __init__.py | |-- models.py | '-- views.py |-- projectx | |-- __init__.py | |-- errorsbase.py | |-- errorsdrf.py | |-- settings.py | |-- urls.py | |-- wsgi.py |-- manage.py |-- modules | |-- __init__.py | |-- auth.py | |-- base.py | |-- connectors.py | |-- sorters.py | |-- threader.py ` |-- models.py
Coding Conventions
Throughout your code, the coding conventions of PEP8 should be followed. This will ensure both naming conventions and code layout is produced in a clear and consistent manner.
Below is a small example of the key points,
Naming Conventions
module_name package_name ClassName method_name ExceptionName function_name GLOBAL_CONSTANT_NAME global_var_name instance_var_name function_parameter_name local_var_name
Code Layout
Logging
Logging provides a method of ….
Logging is configured by,
- using the inbuilt logging features of Django. Using the configuration below.
- logging events will be placed,
- within the main.py by the
- return (info)
- raise (error)
- within the base.py
- end of each function (debug)
- within the main.py by the
// settings.py LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'formatters': { 'verbose': { 'format' : "[%(asctime)s] %(levelname)s [%(name)s:%(lineno)s] %(message)s", 'datefmt' : "%d/%b/%Y %H:%M:%S" }, 'simple': { 'format': '%(levelname)s %(message)s' }, }, 'handlers': { 'file': { 'level': 'DEBUG', 'class': 'logging.FileHandler', 'filename': 'projectx.log', 'formatter': 'verbose' }, }, 'loggers': { 'django': { 'handlers':['file'], 'propagate': True, 'level':'DEBUG', }, 'app1': { 'handlers': ['file'], 'level': 'DEBUG', }, 'app2': { 'handlers': ['file'], 'level': 'DEBUG', }, 'appX': { 'handlers': ['file'], 'level': 'DEBUG', }, } } // main.py import logging logger = logging.getLogger(__name__) def myfunction(): do something ... logger.info("do something")
Exceptions
Exceptions should be placed as close to the error as possible. And caught at towards the top layers of the application. This will typically be within the view of the application.
Custom exceptions will added to the following files within the ‘projectx.py’ directory.
errorsbase.py
Below is an example. All custom exceptions will be subclassed from CustomBaseException.
# General Exceptions class CustomBaseException(Exception): pass class VersionError(CustomBaseException): pass class ParseError(CustomBaseException): pass class ConfigError(CustomBaseException): pass class InstallError(CustomBaseException): pass
class CustomBaseException(Exception): pass class VersionError(CustomBaseException): pass class ParseError(CustomBaseException): pass class ConfigError(CustomBaseException): pass class InstallError(CustomBaseException): pass
Subclassing allows for the base class to be caught rather then having to catch each of the exceptions. Below shows an example. It is also recommended that you do not print the contents of the exception under the general exception. This is to ensure that details of the application are not exposed to the client
try: do something wrong except CustomBaseExecption, exc: print exc except: print "General Error"
errorsdrf.py
django rest framework exceptions.
- How to Configure a BIND Server on Ubuntu - March 15, 2018
- What is a BGP Confederation? - March 6, 2018
- Cisco – What is BGP ORF (Outbound Route Filtering)? - March 5, 2018
Want to become a Django expert?
Here is our hand-picked selection of the best courses you can find online:
The Complete Web Development Bootcamp course
Django Practical Guide course
Django Full Stack Developer Bootcamp
and our recommended certification practice exams:
AlphaPrep Practice Tests - Free Trial