{"id":14139,"date":"2025-02-25T14:14:31","date_gmt":"2025-02-25T14:14:31","guid":{"rendered":"https:\/\/capitole-consulting.com\/?p=14139"},"modified":"2025-06-20T09:47:06","modified_gmt":"2025-06-20T09:47:06","slug":"code-development-tips-unit-tests-code-formatters-and-stylers-and-structuring-code-as-a-package","status":"publish","type":"post","link":"https:\/\/www.capitole-consulting.com\/fr\/blog\/code-development-tips-unit-tests-code-formatters-and-stylers-and-structuring-code-as-a-package\/","title":{"rendered":"Code Development Tips: Unit tests, code formatters and stylers and structuring code as a package."},"content":{"rendered":"\n

In line with the previous article \u201cStructure, readability and efficiency in code development<\/em>\u201d<\/a>, I add some practical tips to improve Python development practices.<\/p>\n\n\n\n

As you know, in Capitole we have presence in many different industries. Many of us are in data processing projects, in Data Science \/ Development \/Devops positions and work both on physical servers and on cloud machines in AWS, Azure or other cloud services. For us it is very important to work efficiently and follow good practices in development<\/strong>, leaving a good image of our company wherever we go. This allows us to perform our job the best we can and makes things easier for the end customers of the developed product.<\/p>\n\n\n\n

In this article, we share some of the thoughts that we have acquired over time, that are meant to help as tips to organize the code. They are simple tricks that can save a lot of time and misunderstandings in the day-to-day work of the team of developers.<\/p>\n\n\n\n

Inline Tests<\/strong><\/p>\n\n\n\n

I know you test your code; otherwise, how do you know it works? But here\u2019s the question: do you keep track of the tests<\/strong> you do? If not, how can others trust your code?<\/p>\n\n\n\n

Welcome to the amazing world of unit testing. This is one of those things that might not seem fun at the beginning, but once you\u2019ve experienced long hours wasted debugging code, and then hours saved thanks to testing your code, it magically becomes fun and a must.<\/p>\n\n\n\n

I would want to teach you about the assert<\/em> statement, also known as \u201cinline tests\u201d<\/strong>. These tests are useful to check if the input and output of your functions are correct.<\/strong><\/p>\n\n\n\n

Let me show you an example where this comes in handy. Let\u2019s say you are working with a vector of probabilities, and you want to project to 0 or 1 depending on a threshold. This function is implementing this:<\/p>\n\n\n\n

def <\/strong>project_to_zero_or_one(probabilities, threshold):<\/p>\n\n\n\n

# define empty array<\/em><\/p>\n\n\n\n

projections = np.empty_like(probabilities)<\/p>\n\n\n\n

# project<\/em><\/p>\n\n\n\n

projections[probabilities < threshold] = 0<\/p>\n\n\n\n

projections[probabilities >= threshold] = 1<\/p>\n\n\n\n

return <\/strong>projections<\/p>\n\n\n\n

But what if there are nans in your input vector? What if one of the entries is <0 or >1? (remember probabilities are not defined outside the range [0,1]) What if the input is a matrix and not a vector?<\/p>\n\n\n\n

I would like the code to tell me if anything like that is happening, meaning there\u2019s something wrong somewhere else I need to fix before it\u2019s too late.<\/p>\n\n\n\n

def <\/strong>project_to_zero_or_one(probabilities, threshold):<\/p>\n\n\n\n

# check input<\/em><\/p>\n\n\n\n

assert <\/strong>probabilities.ndim == 1, \u00ab\u00a0Input must be a vector!\u00a0\u00bb<\/p>\n\n\n\n

assert <\/strong>np.isnan(probabilities).sum() == 0, \u00ab\u00a0Input contains NaN values!\u00a0\u00bb<\/p>\n\n\n\n

assert <\/strong>np.sum(probabilities > 1) == 0, f\u00a0\u00bbThere are probabilities > 1!\u00a0\u00bb<\/p>\n\n\n\n

assert <\/strong>np.sum(probabilities < 0) == 0, f\u00a0\u00bbThere are probabilities < 0!\u00a0\u00bb<\/p>\n\n\n\n

# define empty array<\/em><\/p>\n\n\n\n

projections = np.empty_like(probabilities)<\/p>\n\n\n\n

# project<\/em><\/p>\n\n\n\n

projections[probabilities < threshold] = 0<\/p>\n\n\n\n

projections[probabilities >= threshold] = 1<\/p>\n\n\n\n

return <\/strong>projections<\/p>\n\n\n\n

One practice I like to follow is extracting all assert statements out of the main function<\/strong>. This is particularly useful when you have other functions that use the same argument, such as probabilities, allowing you to reuse the code.<\/strong><\/p>\n\n\n\n

def <\/strong>_check_probabilities(probabilities):<\/p>\n\n\n\n

assert <\/strong>probabilities.ndim == 1, ‘Input must be a vector!’<\/p>\n\n\n\n

assert <\/strong>np.isnan(probabilities).sum() == 0, ‘Input contains NaN values!’<\/p>\n\n\n\n

assert <\/strong>np.sum(probabilities > 1) == 0, ‘There are probabilities > 1!’<\/p>\n\n\n\n

assert <\/strong>np.sum(probabilities < 0) == 0, ‘There are probabilities < 0!’<\/p>\n\n\n\n

Code formatters and Stylers<\/strong><\/p>\n\n\n\n

You may not realize it yet, but you\u2019ll spend most of your career reading code instead of writing it. Whether you work in a team and review your colleagues\u2019 code, or when you are trying to solve a problem by looking for an answer on StackOverflow, or even when you come back to debug code you wrote months ago. In all those situations, you will be reading a lot of code.<\/p>\n\n\n\n

For that reason, it is important to write code in a consistent and uniform way.<\/strong> This includes decisions such as maximum line length, empty lines between function definitions, and syntax conventions like vector[:-1] or vector[: -1]. These may seem like small details, but they have a significant impact on code readability for humans. The big question is, can all these small decisions be automated<\/strong>? Yes, indeed.<\/p>\n\n\n\n