Learn to Refactor a Large Grasshopper Script with a Real Model
Hi there,
Today, we are looking at the final part of the long 4-part series on the Winton Guest House. In the previous parts, we focused on modeling and exploring different methods to create the geometry that we want.
But with all that geometry processing, we need a way to make sure that when we come back and look at the script, we can recall the script’s intent and process. We need to futureproof the script.
To do that, we need to refactor the current script to make it more readable. Which is the focus of today’s article.
Refactoring is a term that is largely used in the programming environment to move and delete code in an attempt to make it more readable.
It is a fairly large script which means I won’t be showing you all the refactoring that I am doing because that would just take too long. Not to mention, you can download the refactored script here.
But what I will show you instead is parts of the overall refactoring that I think demonstrate the overall intent and process.
Refactoring
So, let’s first start off with a bird’s eye view of the current state of the script.
I find it already hard to understand the script after a couple of days, imagine what it would be like to look at this script after a couple of months. This is precisely why we need to refactor this script.
It normally takes quite a bit of effort to refactor an entire script. Not to mention, once you have finished the script, it is quite easy to dismiss the refactoring step. This is why I have made it a habit to refactor portions of a script rather than the whole script. I.e. when I reach a stopping point in the script, I would do some refactoring.
We are aiming for our script to look something like this:
I am going to start chronologically by working my way from the left to the right of the script. Let’s take a look at the first few components top right of the script.
You can see that there is a part of the script that creates the geometry for the cube building of the model. So I can use data containers to separate that out and add a Scribble component that labels what this portion of the script is responsible for.
From there, I look to the right and apply the same concept to the part of the script that creates the chimney building.
Notice that I have also added a smaller Scribble that tells me that I am using the List Item component to select an edge. Then I move on to refactor the components right below this part of the script.
Straight away, I can see a part of the script that I can separate because it looks like a good point of separation. This is denoted in the green box below.
I can tidy that up, use data containers to replace the output/input, and label it with another Scribble component.
One thing that you might have seen now is that using data containers really helps tidy things up. They let you hide wires and make the portions of your script look more modular.
By now, I think the refactoring pattern here is obvious. It is all about identifying stopping points in the script, separating them for some room, and tidying it up using data containers.
So instead of me repeating the process again and again for the entire script, it is a better idea to just show you what each part of the script looks like now.
So, moving a little right where I create the central prism, the script looks like this
Then moving a little lower in the script,
and some more,
and then to the top trailer buildings.
I could have separated out the script more here but I thought this was good enough. I find organization and refactoring to be a recursive process and you can always take it a step further. So don’t separate components out too much because some components should stay together.
Fortunately, when to stop is something that comes with experience, so the more you refactor, the better you will get at refactoring.
With most of the script organized, we come to the part of the script that creates the leaf building using the solid intersection.
Aside from modularising the logic, I would also create a white panel and write down some notes. Because the logic is fairly complex here and it might not be obvious what the components are doing. Taking notes leaves me with enough breadcrumbs to understand it again if I need to.
Final Thoughts
and with that, we finished organizing and refactoring the script now looks way more organized and readable than before.
It definitely is a lot easier to understand the different parts of the script as well as how the different bundles of processes are related to each other.
The fruits of this refactoring process will come when we need to dive back into the script to make edits or if you need to refer back to this script to copy a snippet of the process.
We will inevitably forget about what we have done in the script, therefore, refactoring and organizing the script makes the re-understanding process a lot less painful. This is why I think refactoring your script is almost always a must and is a best practice when it comes to scripting in Grasshopper.
As always, thanks for reading,
Braden.
P.S. I would love to hear from you about the article or if you have any suggestions for future topics, leave a comment below or email me at bradenkoh@braden.com
Resources
The Youtube version of this Article :
You can find the Grasshopper Script for this model for free here
(Just Set a Price of 0 dollars)
Read the Previous Article :
Originally published at https://allthingscomputational.substack.com on May 11, 2022.
