Video Transcript

Hello everyone! Welcome back to This Not That, a Vlog where we talk about a best practice and contrast it with a common mistake that we see here in the BI (Business Intelligence) industry. Today we’re going to talk about writing code. So let’s get into that.


The topic we’re talking about today is how to write good, quality code. So this is mostly going to happen in that 2nd stage of BI when you’re doing your data cleaning and sometimes in the 3rd stage when you’re doing analysis. Most data analysts have had the experience where you are given a piece of code, start to read it and quickly realize it is illegible, impossible to interpret and no one can make heads or tales of it. Maybe you’re coming in behind someone who told you “my code is so good it documents itself!” and it turns out he/she was lying to you. This is a problem that I see on a regular basis.


So as a best practice, remember when you’re writing your code remember that you need to write English not computer. Write in ENGLISH. So what does that mean?


There are a few simple ways you can ensure you are writing in English not computer:

 

  1. Use white space. There are plenty of languages like Python that require white space and plenty of other ones like Sequel that don’t care about white space. Regardless of the language you are using, use white space. Use formatting like indentions to line sections of your code up and let people know when it begins and ends.
  2. Inline documentation. A second way to act to ensure you are writing in English, not computer, is to make sure that you have documentation. Take a moment to put a line at the top that explains what the code is. Think of Simon Sinek, “Start with the why.” Why does this code exist? Then get into what does it do and how it works, but start with that why. Explain to someone up front why they need to read this at all.
  3. Avoid abbreviations. A 3rd suggestion for writing English Not Computer is to actually use English words instead of abbreviations. Computers are just as capable of reading abbreviations as opposed to something that is all the way written out. But WE are not. So, take the time- I know it’s a pain- but take the time to sit down and write clear and complete code. Instead of having a table called A for example, actually label the table by it’s full name.


If you’ll do these things: pay attention to white space, add those inline documentation notes and take the time to use real words instead of abbreviations, your code will be legible and understandable not just for you but for anyone who comes after you and they will thank you from the bottom of their hearts that they didn’t have to figure this thing out on their own.

 

If you enjoyed today’s topic, I encourage you to leave a comment below with your own thoughts. Or if you have an idea for a best practice that you’d like to see used more often here in the BI community, by all means let us know. You can follow us on social media or head to our website.