The world’s leading publication for data science, AI, and ML professionals.

Python: 6 coding hygiene tips that helped me get promoted.

In this article, my top 6 obvious but not always applied coding tips that I wish someone forced me to follow 3 years ago and that I will…

Photo by Nghia Le on Unsplash
Photo by Nghia Le on Unsplash

Ok, let’s go!


I will do my best to keep this article as clear, concise and neat as possible. I want to share with you the essence of these tips and not go on too much wordiness.

If you are too lazy and just want my top 6 tips, you can jump until the end of this article where I am giving a recap.

These pieces of advice are coming from my own experience and can be used by anyone coding on R, Python, VBA or SQL.

I have been working as a data scientist for 3 years and these pieces of advice have been given to me from people who managed me since I started my career after graduation.

Enough talk, let’s pick a cup of coffee and start. (Even hot chocolate will do the job :)).


Let’s start with the tip number one …

1. Always comment your code and explain why you do it.

Tips number one: Comment your Code!

This tip is the most repeated and the most important of this series because no one can deal with an uncommented code. That will make your colleagues and reviewers waste time.

You should always comment your code and more importantly explain why you are doing something.

Remember: a well-documented code is as essential as a correctly working code.

Before delivering any code or model to the client, give 30 minutes to comment and explain each series of lines. If the deadlines are short, consider adding one hour or even half-day if you believe it is necessary, but comment it. You will gain as much time when you will have to refresh and maintain your model.


2. Keep your code dry; do NOT repeat yourself.

Second tips: Keep your code dry!

I know this advice looks a bit silly, but that’s happening. In each script that I reviewed, there is always some unnecessary lines of code or some steps which are repeated multiple time.

So, please, keep your code short and as dry as possible and the world will be happier.

We will be best friends then :).


3.Keep all variable names in lower case.

The third piece of advice: variable = lower case only!

If there is something that will make you avoid leaving work at 9 PM on a Friday night is the following one.

Your model can crash for so many reasons, but avoid wasting time and making it crash because of an upper/lower case variable issue :).

Promise me that you will always keep your variable name in lower case mainly if you are coding on Python.


4. Consistent naming convention. Do not deviate, please!

Advice number four: follow the initial convention.

If you start naming your variable by a certain way for instance:

datevariablenamedigit (_20200715_dftesla2)

Don’t switch to this type of variable name in the middle of your script:

variablenamedigitdate (_df_amazon_220200715)

I believe you understand my point, but that just makes the code harder to read and follow for the reviewer.


5. Test and reconcile your code

Fifth advice: Test your code!

Before to start, always consider what tests can be written alongside your code in order to check the validity of your assumptions and logic.

Furthermore, ensure that you have not lost or altered any Data along with the data processing.

Two short test examples that you must tick before sending any code to the client:

  • The total number of rows from the initial dataset vs after each join. (If you are making a union, the sum of both datasets). If you are making a group by, compare distinct values from the initial dataset vs after the ‘group by‘.
  • The total amount for each column of the initial datasets vs total amount after each transformation must reconcile.

6. Listen

Last piece of advice: Listen!

Sometimes listening is very hard. You may think that you understood the problem or that you already have a point of view on how to tackle the situation. But sometimes you can just go in the wrong direction.

For this reason, learning to listen is a skill on which you should work. You can learn so much from your colleagues and more experienced people. I remember I spent so much time after work talking with my colleagues. And listening to their point of view. Learn how to be an active listener and you will win.

Here a brilliant article which influenced me from another TDS author:

Learn How to Listen

That’s why I want to hear your opinion and your voice. And let’s chat about it in the comments.

Two questions:

  • What would be your top 3 pieces of advice?
  • Which extra tips would you add/remove?

I will be happy to read and listen to you.

Furthermore, here an extensive list of other tips which could have been included:

  • Keep your code short
  • Combine related function and attribute into class
  • Use a separate config class to set shared variables.
  • Ask for a test if someone altered your model before you.
  • Use version control.
  • Always keep track and date your change.
  • To be continued…

If you code on Python and you want some nice tips for coding, I highly recommend this Youtube channel:

https://www.youtube.com/channel/UCZorZ8KWmTON7aO84JJBwlQ?


A brief recap of the top 6 tips:

  • Always comment your code and explain why you do it.
  • Keep your code dry; do NOT repeat yourself.
  • Keep all variable names in lower case.
  • Consistent naming convention. Do not deviate, please!
  • Test and reconcile your code
  • Listen

Thank you for your attention,

Happy coding


Related Articles