There’s something that’s been on my mind for a while. Show me your canvas organization…
When I first taught Grasshopper, there were no public models of good canvas organization. I taught it but that only goes so far. It was so bad that I didn’t want to see people’s scripts, but there was this (dumb) convention in architecture schools to put a screenshot of whatever rat king they were making on their project boards. In rare cases they had one that helped show how clear their thinking was.
I have finally converted enough students to clean visual coding that I feel comfortable being more demanding - if someone uses Grasshopper, I WANT to see their canvas. Because a clean canvas means clean thinking.
So - I’d love to get a thread started with examples of scripts which you think model “clean coding” in Grasshopper. I have more sophisticated ones, but they’re working tools for me and I hesitate to let others in on my thinking. So I’ll start with this one from a class I taught as an offering…
Grasshopper canvas, where spaghetti meets architecture! I feel you. it’s like asking to see your spotless kitchen during a dinner party, but hey, if you’ve got it, flaunt it.
I prefer to enjoy watching
I have worked in many different projects with partially very strict metrics on visuals scripting and code. Not exclusively Grasshopper but also Simulink, and similar visual scripting applications.
I think the most common criteria to follow, is subdividing the definition into parts of single responsibility with a limited amount of in- and output. Either by grouping them visually or by using subsystem features like “Cluster”.
It helps to explain in 3 easy sentences what such a software component (not GH component) does. If you need more words, you divided not good enough.
Also note that you can differ in between an input & output boundary and parameters to tune the algorithm. Tuneable parameters are there to optimise an algorithm from a developer perspective, whereas the input and output boundary is rather meant for the user/consumer. Such a person would not necessary need to understand the internals of this “black box”, therefore it makes sense to highlight and validate the in- and output boundary (“interface”) of your definition.
Anything else is quite subjective and a matter of personal preference. But its good to agree on one style if you work in a team.
#1 create subroutines - blocks of code that “Do One Thing” - what that one thing is depends on what the writer is doing, but these tend to be 10 to 50 function blocks. Subroutines are grouped, named and labeled with a scribble (use metahopper!!).
#2 All data into a subroutine on the left, All data out on the right, All data enters and exits via named parameters. No functional block is to have a connection outside of the subroutine! When built this way each subroutine is actually “cluster ready” though I find trouble shooting much easier with a “flat” canvas rather than having subroutines inside clusters.
