You cannot extract the code as such. If the built-in python node is used, you can edit that and get the code. You cant get the code if it is a Zero-touch node. However, many share their code at GitHub.
I started out doing like “Ladybug” (@Mostapha) but experienced difficulties with that method. I got a bunch of error-feedbacks from mid-November to end-December. I don’t know what went wrong with that method, but I ended coding a binary file instead. That is the method e.g. @Konrad_K_Sobon use in BumbleBee. It seems to be more failsafe, not that I can tell why it wasn’t that with the other method. I cant understand why the former should go wrong.
Where Ladybug has most of the code outside as py files, has BumbleBee it inside the dyf files supported by binary files. I have all my code except the “reader” node as py files in a lib folder (in the extra folder) I use the name ‘lib’, since that is a Python phrase, ‘scr’ is a Java and C phrase.
Having all my code in native py files gives me the advantages to use VSC and sharing the code with others at GitHub that doesn’t know dynamo as such. The code is readable as well-known files not as ”messy” text in a dyf file-format not known by anyone outside the dynamo world.
I have also tried the best to follow the PEP8 standard, but it is difficult when there are some requirements from the Dynamo environment that works against that. When you initiate IN and OUT variables then it will fail a PEP8 test, likewise goes for loading external modules. Some have to be loaded in a certain way demanded by Dynamo (and .net).