Huge file rvb


I have a small problem (actually is quite big for me)

I was hired recently and I’m supposed to be the only developer (the previous one quit). I have coded in C# even for Rhino but never coded in VB or RhinoScript.

I found that all tools developed here in RhinoScript are included in one single rvb file (I don’t know if this is a good idea). This file can contain about 15000 lines and over 100 Functions or Subroutines…I think this is crazy, but there is very hard work behind.

My problem is that when I want to debug the script Rhino remains thinking and thinking (over 1 hour) and finally I get upset and I close Rhino in hard way. I tried debugging with smaller scripts even with multiple functions or Subroutins and everything works right…

Can anybody help if this is normal and if there is anyway to debug such a big file? I don’t know if the amount of lines and functions is the reason for this problem…

Thank you!

1 Like

Hi Vito,

RhinoScript debugger will either freeze or take forever on larger scripts, if you have more than 2000 lines of code I would say, sadly, you should not rely on using it…


Thanks for your fast answer Jarek!

Is there any solution or idea how can I debug this monster?

I am guilty of creating such monsters myself, that go beyond what the current far-from-perfect debugger can handle. The only way I was dealing with it is to put an Exit Sub/ Exit Function where the breakpoint would be and before that add some codes to print the values of the variables in question. Far from efficient, I know…

You need to refactor. But there’s a business context to this, so:

Step 1: manage expectations: tell your boss you’ve inherited a can of worms because the code can’t run in the debugger. You’ll have to refactor. Anything non-critical in the backlog will have to wait.
Step 2 (assuming your boss accepts step 1): Review the code. Is it well commented, so you can follow what is ostensibly happening? If not, is it externally documented? If you don’t have commentary/documentation it’s time for more expectation management…
Step 3: Start to refactor. No regression testbed? More expectation management…

Good luck!

1 Like

Another way to try to deal with it would be to break up the single rvb into independent smaller pieces but that depends on the structure, organization and how “tangled” the code is. Sounds like a nightmare to inherit.

Thank you guys! Everything you say make sense!

I’ll think about those different ways you are proposing…But there is no documentation or comments at all. Nothing.

Can we get to a conclusion here? For such a big projects (and if you want to work debugging of course), coding in enviroments like Visual Studio or similar is better?

A lot depends on business context. Are you there to maintain the Rhinoscript or to create new functionality? Did your boss hire a C# developer because they want to move away from Rhinoscript? Yes, Visual Studio provides better facilities for development (but AFAIK no-one has created a Visual Studio environment for Rhinoscript).

If I had to deal with your Rhinoscript I would pull it into a good code editor like UltraEdit and use that to start cross-referencing procedures and functions to find the interactions. Then split out a small self-contained group of them into a separate file and start to add comments. That will start to give you an insight into the previous developer’s mind. Then repeat with further self-contained sets of procedures and functions of greater and greater complexity. Divide and conquer is the watchword.

When it comes to breaking down your large file into a set of more manageable small ones, the following may be useful:

Again, good luck

1 Like

Thank you so much Jeremy!

I’m here to create new functionality inside this “monster” and also to fix several bugs or errors detected…

As you say, I have to sit down with my bosses (they have no idea about coding) and show them this situation. I feel quite unconfortable with this, because I have to explain I don’t agree with how it was done (by other who is not already here), and I have to spend quite lot of time refactoring and creating documentation, which is very “unproductive time”.

But, I have clear all implicit benefits…so this is time investment.

Thank you once more!

I’d advise you to lose this mindset. It is actually the most productive time, because everything you do thereafter will be done more quickly and with less risk of error than if you hadn’t grasped the nettle.

I wouldn’t start on new functionality until you have some understanding of what is there already. But if there are bugs to find and fix, try to work them into your refactoring so that when you deal with a portion of the code you can also fix a bug and deliver tangible benefit as well as intangible.


How far back does the existing code go in time? Most likely it got to what you see by “growing like topsy” over a long period by a person (or several persons) who “learned by doing”. If you begin your planning discussions with management by mutually understanding the history you will probably be able to discuss the future in terms that don’t insult or disparage your predecessors or management and create a reasonable set of mutually acceptable goals and plans. And what Jeremy said. :grinning:

Yeah @jeremy5 , I totally agree with it. I was just showing what managers can (not sure) think about this.

Thank you @AlW!