WEEK 9 DRY CODE

[eculler]

Over the next few weeks, we’ll be working on modularity in Python.

Readings for this week:

1. DRY code at earthdatascience.org
2. What makes good code good? from the Software Carpentry blog

[eculler]

Thursday 1pm section - pseudocode for the Urban Green Space Assignment

Problem statement: Calculate summary statistics of NDVI for all the neighborhoods in Chicago

Normally we'd download NAIP data all together, but in this case we don't have computing resources to have all the data on the disk at once.

• Download vector polygons for the neighborhoods
• Define a file path to save statistics in
• IF that file already exists:
  • Load in the file
• ELSE:
  • Initialize a DataFrame that has all a row for each neighborhood and columns for the statistics
• Loop through the neighborhoods. FOR EACH neighborhood boundary:
  • IF the statistics are NOT already saved for this neighborhood:
    • Apply a function that
      • TAKES IN:
        • bounding box for each neighborhood
        • neighborhood boundary
        • statistics DataFrame
      • PUTS OUT: Summary statistics as a DataFrame row
      • does:
        • Download NAIP multispectral raster data for the neighborhood
        • Find all of the file names of the rasters
        • IF there are more than one:
          • Merge rasters
        • Clip (box) the NAIP data to the neighborhood envelope
        • Clip NAIP data to neighborhood boundary
        • Calculate NDVI
        • Calculate statistics
        • Delete NAIP data
    • Add statistics to the DataFrame
    • Sync the statistics in a file

[ellenalamont17]

This week's reading provides some great and simple guidelines for writing good code. It is suggested that your code should be readable, accurate, robust, efficient, flexible, reusable, and well-documented, among others. Being DRY goes a long way toward making your code as simple and clean as possible. Creating functions to avoid repetition not only shortens the overall code length, but it also allows you to create independent descriptions of the functions in the function's code, improving code readability and clarity. It further gives you the ability to reuse sections of code across multiple projects. The use of loops and conditional statements reduces code length and sometimes computational burden by not caching numerous variables to store individual process results or repetitively downloading datasets.

The problem with coding, in my opinion, is that it is easy to fall into the trap of thinking that you will go back into the code after you've written it to clean and comment your work, but never really getting back to it. Writing good code takes time and energy that we do not always have available, and it does not always feel like there is an incentive to put in the effort. However, if we can get into the habit of commenting as we write code and using algorithms or pseudocode before writing our code, the task of creating simple, accessible, and readable code can become far less daunting. It can also become easier to debug code when the code components are clearly demarcated, saving time and energy.

When discussing ways to make our code more readable and simple, we got into a discussion naming variable that I found to be both interesting and tricky. How do we strike the balance between being specific about the variable in the name and reusability for the code in other processes/analyses? For example, let's say we are looking at data for a specific fire. We might choose to call that variable camp_fire_gdf . Such a naming scheme works well for analyses of the Camp fire. However, what if you wanted to use the same code to look at another fire? Your option would be to go in and change all the variables with "camp" in the name or you could choose use a more generic but still descriptive name from the beginning to make the code quickly reusable. For example wildfire_gdf could be used for the fire and kept generic. How might this generic naming make the code more or less readable? understandable? flexible?

[peterkobylarz]

@ellenalamont17 Good points about habits, coding, and good intentions! I am definitely guilty of coming back later (or meaning to and not!) to add comments. I agree that like anything, coding is about developing good habits, and one of the best habits we can do to save ourselves time later and write better code is to comment everything the first time around.

The "coding for yourself" bad practice mentioned in the second article is relatable as well. I often find myself needing to resist the urge to use comments as an internal monologue. Comments in this fashion will likely not be useful to other readers and probably won't actually capture the intent of the code. Comments should be informative even if this means they are boring.

[annettebalmes]

I ran into this during the chicago neighborhoods functions assignment. I started writing all my functions using neighborhoods, but I realized that a lot of the functions I was writing could be used for other purposes, not just neighborhoods, I then went through and started changing the names of everything, and it took me like twice as long to write my code because I didn't sit down and try to write it dry in the first place!

[annettebalmes]

In the coding world, people use different ways to write code – some good, some not so good. Even if both types of code seem to work fine, badly written code can cause problems during development, fixing bugs, and making changes. In the professional world, someone else will probably need to read or change your code at some point. It's much better for everyone if the code is easy to read and understand.

Understanding why good code is important involves looking at what can happen if your code isn't great. Poorly written code can lead to losing money or wasting time when you need to update or fix the software, because you have to spend so much time even understanding what the code does, whether you were the one to write it or not.

You write your code once, but you'll have to look at it many times later on. So, keeping good notes about your code and using clear names for things are really important. I know so many people that say that they do not remember what code or logic they wrote a few days ago. If you write good, dry code, there's no need to memorize what you did, your code will do the work for you.