Happy Snakes — Data Point #4

Development

The new term has started on this capstone and we really have hit the ground running in our team. There are lots of moving parts and lots of code to get our heads around. All of our development is in Python at the moment, and because of this I found an article on dev.to by Alex Omeyer who writes about tips on how to write clean python code.

Takeaways on Writing Clean Python Code

    Naming

    I always thought that short simpler names were more efficient in coding. In terms of writability that used to be true. With newer coding conventions like predictive suggestion (When you are in your IDE of choice and you type a declared var and you just have to press enter for the IDE to type it for you) you don’t have to type out the entire name of a function, variable, or class – most IDE’s do it for you. This means that names can be long and descriptive for the user to see.

    I can now go from:

    def trace_generator(traces: ndarray) -> generator:
        """
        Code goes here
        """
        pass

    To:

    def generate_trace_by_row(traces: ndarray) -> generator:
        """
        Code goes here
        """
        pass

    See how descriptive it is! Now anyone on my team can see that this function only returns a generator for a row.

    Do One Thing

    This one is simple… at least it should be. I am lazy sometimes and have multiple functionalities in my function. Having your function do one thing well, if you need to do two things thats a subclass or a new function. This keeps things short, readable, and simple.

    Keep it Modular

    Upon visiting my home state of Oregon, USA, I go to MOD Pizza. At MOD they have steps. First Pizza base, then sauce, then cheese, then toppings, then extras. Each pizza is MODified, and their process is MODular. Our code should be like this too. Each feature, component, or part should be its own module. It doesn’t matter if thats a directory or its own .py file, thats up to your system design and needs. The point is that it should be separated into logical units that make sense to your team and future users/developers.

    pizza with green leaves on top

    Smelling Your Code

    How do you smell your code? Pro tip – don’t sniff your screen, senior developers will look at you funny. In an article on dev.to by Joe Eames they discuss how a code smell works and what they are all about; a code smell is a way of improving code beyond debugging and problems. A code smell is code that smells funny, it’s “off.” Some examples would be things like a function that does more than one thing, or a class that is thousands of lines long. Any code that can be improved by simplifying our code and making it less offensive, like lighting a candle after taco bell.

    tea light on brown surface

    In Practice

    Through the course of this term my team and I will continue to offer advice and critiques on each others code through code reviews. In this I believe that we can smell each others code through code reviews and all become better programmers together.

    Leave a Reply

    Your email address will not be published. Required fields are marked *