Our computational team is getting bigger and more people are coming in with varying skill level. The issue I’ve seen with GH (and most visual scripting) is that things can look like spaghetti code very quickly. Is there some resource/ tips and tricks that can point us to commenting and writing GH scripts properly. I was thinking something similar to pep8 in python but GH.
My aim is to make script more legible for any skill level to jump in and read. Plus I guess this is a pretty good ethic for everyone sharing scripts in the internet.
Some people like to use Scribbles to annotate stuff, others like Panels or a combination of both.
In order to avoid everything looking like spaghetti you can neatly arrange the components in relation to each other, partition relevant parts of the definitions into groups - which can also be annotated - and edit the wire displays to be less obstrusive, where you visually don’t need it.
I would make a template with vertical lines to strucutre the process and group colours(like layers and ctb), also restrict the max. component count and break the defs into smaller chunks with data input/output or hops.
If others only need to use (i.e. not modify) the definitions and there is concern that spaghetti code will put them off or makes it hard to know what parameters can be changed and what should remain as-is, you could move the core definition to one or more separate .gh file(s) and use the Hops component to access these from a definition that holds the controls that the user should use.
Or use GrasshopperPlayer and keep Grasshopper completely behind the scene.
1.) In GH you can import curves from Rhino as scribbles. This allows you to draw little sketches. A tiny sketch is sometimes much more descriptive.
2.) Subdivide your definition into “black boxes”. A user doesn’t need to know how it works, but it has to be clear what it does. You can use clusters, script components or just grouped components. A black box is fully encapsulated to the outside.
3.) Minimize the parameters of your system and your “black boxes”. Define clear In and Outputs. Highlight them.
4.) Find meaningful names and explain why and what it does, not just what it is.
5.) Single Responsibility. A “black box” has one single purpose, not 2 or 3. Sounds simple but is really hard to enforce
6.) Open-Closed principle. Close for modification, Open for extension. A “black box” is never modified, but exchanged. Two “black boxes” can be interchanged by each other (see 2,3,5). It is not required to overwork A if B changes. Don’t change A, but replace B by B’. Therefore, a black box needs to have a clear interface.
Try to prevent changing this interface.
7.) Guard against stupid input. Give meaningful error messages
8.) Provide a diagram (like UML) to overview the system (GH Definition).
9.) Provide documentation.
10.) Always Refactor
11.) Move proven tools into a plugin.
12.) Develop your “black boxes” isolated and test them.
As you might have noticed, I have interpreted the SOLID programming principles. Unfortunately, you can not fully apply them to Grasshopper. Especially, the “injection” of logic/code from outside a black box is not directly possible, because you can not provide components as parameters. Which means you cannot really practice dependency injection techniques.
But speaking of some programming guidelines, there is something I would also mention because I see it very often in Grasshopper.
Be careful with dependencies! It is good to write a plugin or a “common” library for your own team or company. But relying on external dependencies (=plugins) is a great risk. You might want to migrate to a new Rhino/GH version, but your plugins won’t be updated = Problem. Also, you can never trust third party developers. You might get malicious code or vulnerabilities on purpose or by accident (=“log4j” ). You might not get the binaries or not in the right version years later… Or a plugin causes weird errors, performance issues or cause a wide range of other issues by accident. If it’s just a fraction of what a plugin provides, then consider investing the time to reinvent the wheel!
And last but not least. Keep things as simple as possible, but as complex as required. Some advanced users really like to show off their skills and overcomplicate all day. That’s an issue I encounter daily in my R&D work. Force yourself not to overengineer something. Always try to explain your ideas in 3 sentences.