Python and Django – The Best Practices

Uncategorised • 7th Aug, 15

 
 

In many instances too much time is spent on a development team trying to understand one another’s code.  This may be a result of the fact that your intuitions about the right way to do something the right way differs, or even that there is a difference of priorities.  More than often it’s due to the lack of any explicit best practice.  Rather than having to justify why you’re so confused, we’ve listed what we feel are the best practices thus far.    Each of these combine to provide you with explicit expectations in order to read one another’s code which will save you time:

  • Version control

- Not including bug fixes, you shouldn’t perform active development on the stable branch   

- To avoid and prevent any merge headaches further down the line, feature branches should then merge from master as often as is feasible

- Four-space tabs are a requirement

- Make use of whitespace liberally

- Make use of lower_case_with_underscores in relation to variable names

- When it comes to non-trivial classes and methods do put explanatory docstrings on all of them

- Sort imports in a logical manner: first standard libraries, then then third-party libraries, followed by your own modules.  Organize them alphabetically to make removing cruft easier

- Always remember: when in doubt, import this   

- With regards to naming, spacing, and so on, follow the Django styling code

- When using pickled model fields, do so with extreme caution

- Rather than using shell scripts, use management commands instead.  This can be invoked programmatically with call_command().

- Do not put logic in templates, put it in view functions.  Always keep in mind: the simpler, the better

  • JavaScript

- Do not use jQuery in widgets of it will end up on other sites

- Other than this, it’s perfectly okay to choose jQuery

- Put JavaScript at the bottom of the page whenever it is possible to do so

- Do not make use of inline JavaScript 

 
  • HTML/CSS

- Add a top level ID to each kind of different page (#candidate-page, #race-page)

- Don’t use camelCase or underscores, but rather hyphens for classes and IDs.

- Formulate descriptive and unique names for your IDs.  Simple generic names can be used for classes

- Don’t rely on things such as min-width, max-width, min-height, max-height, css tables, attribute selectors, pseudo-classes

- Avoid inline styles

- Make sure that the parent block has a specified size in the cases in which you are positioning one block absolutely inside of another

  • Images

- It's quite simple really: don’t use them

- If you do though, make sure to use photoshop’s “Save for web…” or you can figure out another way which you can optimize them

- Images which have many different colours and gradients can be handles with jpeg

  • Testing

- Validate non-trivial methods by using unit tests

- Methods which involve date math, non-ducky type conversions, statistical calculations, or extract data from arbitrary sources should always be tested

We hope you will find them inspirational and if you have any suggestions about how they can be improved, don't hesitate to leave us a comment below! 

 

Back to Blog