Annoyances and tips for Grasshopper version control / development

Grasshopper
1

Hello,

I was wondering if anyone has tips & tricks to share for companies that are using grasshopper in house, and develop workflows with multiple contributors.

When a new flow is created, it starts off nicely structured and clustered up where necessary. After a certain time, the latest version looks like a big bowl of spaghetti. Bugsolving at this stage is like opening a can of worms and finding a needle in a haystack.

Annoyances:
Spaghetti code → Distributing SnappingGecko for cleaner aligned code, urge coworkers to develop more organised

Clusters don’t work anymore → I’d prefer to have Read/Write options for clusters, as code doesn’t need to be hidden for internal use, but editing it should be prohibited. In most cases, things get patched inside a cluster that should be patched elsewhere. These patches are not noticeable from the main file, usually prolonging bug solving time as no bugs are expected in the good old cluster!

Where’s the bug? → Sometimes when a cluster is not working correctly (orange/red), it is still spitting out (partial) data, making the bug troublesome to detect. When a block inside a cluster is orange, this color currently does not get projected on the cluster, which is fine. Red blocks however I’d like to have change the cluster’s color. Also, could we make clusters turn orange/red through phyton script?

Version control → In terms of version control I am all ears for suggestions…
I am thinking of moving frequently used clusters to Hops, in order to update them for everyone more easily. Github-esque version control within the file itself seems like a far away dream. I have seen some Git integrations, but they all seem to work on a file level, which doens’t solve anything in my case. Currently we are just using the classic v1,v2,… v10_final, v11, … format.

Thanks!

2

This is a complicated subject and you will probably get better answers from more experienced programmers how to prevent difficult to track bugs in your code, but what I learned is that it is super important that every block of code has a distinct output and is commented well, and that ideally you should check if the output is correct before sending it up the stack. I haven’t dived into this yet myself, but there are plugins that enable you to do unit testing.

Versioning is quite difficult I think compared to normal code. With normal code you can simply compare what has been added and what has been removed between versions. In gh I think that the best you can do is keeping a document of the changes.

Making definitions can be done quite fast, yet making maintainable definitions is another skill and I found that writing the working code is just a very small part of the exercise. The majority of work is in properly organizing, commenting and checking your code, aka the boring stuff.

2 Likes