I was wondering if you could share screenshots of your neatest, most organised script and discuss the best practices when organizing your scripts. I understand that there isn’t a Pep8 like standard for Grasshopper but maybe we can build a repository of ideas on how to write scripts that can be easily shared and understood?
(I am a student and I work primarily with Grasshopper and feel that this could be such a huge help to me and hopefully others who would love to learn the best practices and develop beautiful and efficient solutions)
Edit: I was hoping you all could share screenshots of well-organized grasshopper scripts that set and increase benchmarks for efficient and easy to understand grasshopper definitions.
Hi Pragya, I currently do professional software development. I think writing Python scripts in a context of Grasshopper and Rhino is by far not comparable to the complexity of writing full applications. (regarding programming)
Therefore applying many advanced concepts and software architectures simply don’t fit the scope. I mean how many additional classes does a python scripts contain? Maybe 0-3?
I think you are fine if you document well, always rework your code for simplicity in reading, preventing code repetetion and nerd syntax . As a bonus write simple(!) unit tests, because full unit tests might be an overkill as well. Maybe a good idea is to start writing a utility module for all your scripts… but to be honest, I never did that when doing Python or C# scripts.
In terms of GHPython, I’d recommend the Google Python styleguide. It offers quite elaborate examples on how to structure and write clean Python code.
In vanilla Grasshopper, I’d say it it’s always a good idea to annotate and/or group related components and maintain a neatly organised component layout.
Thank you for your response. But I feel like maybe I wasn’t clear in my question. I was looking for best practices in Grasshopper. For Python, there are many options for accepted formatting guidelines such as Pep8 and Google Python style guide (like you mentioned). I was hoping that the community can come together and share visual examples of their grasshopper scripts/definitions to create a repository of clean, easy to understand Grasshopper definition organisation techniques. As I have mentioned in my question, screenshots of scripts would be such a good way to go. Don’t you think?
Like you mentioned, annotating and grouping is a great way to go. I was hoping that more advanced users would have figured out some great ways to use these ideas - annotating, scribbling, etc to organise their grasshopper scripts. I am really hoping to see some great examples that can set standards for students like me!
well, there is no right and wrong. Just well documented code and not so well documented code. No matter if Grasshopper or not. Coding conventions are not about to be strict, its about consistency and easy understanding. Every company has its own rules. If you like to follow pep, then do it. But that does not necessary means somebody else can easily read your code.Basically you can understand every piece of code if the documentation is well written, no matter if you know the language or not. This what‘s all about. Make yourself and your teammates to understand your code. That said, its actually mor important to write good documentation, instead of following a good „style“
People still seem not to understand what you mean… could you post a screenshot giving an idea of what you are looking for? I think your comparison with Python meant that people think you were looking for coding guides but I think you actually want advice on arranging GH components on the canvas, annotations, use of colours and relays, …
I have been thinking of posting a screenshot but I genuinely didn’t have an example worthy of someone’s time and attention (which is why the question). But yes, you are absolutely right. (I will try to look for one though)
Also, I know the basics, I’m assuming everyone does - group components and annotate them. But sometimes the way you group and annotate makes the difference in how legible your grasshopper canvas is. I really was hoping for awesome screenshots full of amazing grasshopper scripts.
But thank you so understanding my question! Finally!!! Wohooo.
I was assuming you differentiate between general python programming and python scripting in grasshopper. I think naming it scripting is quite misleading. Anyway, sorry.
Still, my answer still fits in. I hardly see any grasshopper definitions being documented! Annotating is actually extremely rare in grasshopper. But seriously, you could have left out the last sentence, I read this quite arrogant! But maybe we simply dont speak the same language
Hey @TomTom. Definitely, your answer is helpful. I kind of realized that maybe saying script was the wrong thing and hence edited to script/definition.
I am really sorry if that came across as arrogant. I was genuinely happy cause I was hoping to make this thread full of great ideas and images that we can all be inspired from. I love grasshopper and I am so so eager to learn from all of you, there is absolutely no arrogance here, just a super high level of excitement and motivation. So happy to receive your response though!
Several people have written papers about this, I believe I remember one at the 2015 KDAK Design Modeling Symposium and an earlier presentation at ACADIA.
Personally, I use color-coded groups to denote types of script elements ( Adjustable Variables, Import Components, Preview Components, ect. for fast navigation) This is paired with extensive naming of groups to describe in brief the operation occurring, and panel notes where needed. Below is an example that includes more annotation then usual for sharing with collaborators.
I also use a template with Personal or Professional Information in the top left, and some helper meta hopper scripts that allow for consistency in group colors and titles across all scripts
This is amazing Prof. Azel. I think its probably the most well documented and easy to follow grasshopper definition that I have ever come across. Amazing. It is super useful for me and I am sure for others looking for organization tricks.
The examples are annotated with named/nested groups, skribbles, and sketch objects. The examples and their text headings made it very easy to get up and running with the component, as well as to understand its more advanced features.
