[SOLVED] Project grown too huge - best way to maintain it w/ sanity?

Processing Project Guidance
1

EDIT: I’ve decided to switch my project to Eclipse, and completely rewrite it, as it grown badly into a mess of no classes, hundreds lines of code long singular functions, huge load of global variables, and overall spaghetti code I’d like to completely remake.

Original post:

Out of boredom, I’m working on what I want to be a full-on nice 2D platformer game engine thing. The problem is that I’ve got so much code I have to scroll a lot.
At first, I avoided this problem by splitting the code into multiple tabs. However, now I have too many tabs, and it still takes long to scroll in every one of them!

Too many tabs!!
9a8d3441936e929d6fc5509bbf74a120.png1058×67 6.98 KB

I’m thinking of splitting my project up in some nice way, like exporting stuff to a separate library one way or another, but this would mean moving that code out of reach of my fingertips - what if I would suddenly want to tweak some of it?

Should I move on and turn it into an Eclipse project that uses Processing libraries?
I’m kind of scared of that it would be different workflow, as, as far as I know, Processing combines all of these tabs into one long .java file that stores all of the code in a single class, which scares me with thoughts that I would have to rewrite references to functions that I’d move into different files, or something else.

Also, I like using functions that do “magic”, i.e. operate on global values of the whole sketch that are not related to these functions themselves, i.e. changing them. How would I move these functions to a different class while keeping all of their operations on these global variables valid?
By “global variables” I mean the ones you define in Processing code, not in any function, i.e. these:

Too many global variables!!
24b2b15a5748898ae66848ab7739c78d.png187×503 49.5 KB

(yes, I know that this isn’t a good way to do it as these declarations are barely sorted and are all over the place… But eh.)
In other words, I’m scared of having to rework most of my code to turn it into a fine Eclipse project.

What tips do you have that would allow me to turn my code into an Eclipse project with least amount of effort and workflow change?

Or, is there some cool addon or something that would turn the tab interface into a Sketchbook-like list or maybe even a tree so that the project would be easier to work with?

1 Like
2

Yes, you should almost certainly do that.

It would be, but you’re looking for a different workflow.

Well, you shouldn’t. You should “graduate” to proper encapsulation. Also you should almost certainly encapsulate all of those variables into their own classes instead of having one huge list.

There are a few hacks you might look into. For example you might make the variables static and then use a static import. That would get you pretty close to the “magic” you’re talking about, but again: you should not do this.

Processing is great, and one of the great things about it is that it leads you to these more advanced topics. It sounds like you’re ready for the next step. Take it.

2 Likes
3

Before even moving your sketch project to another IDE, you should convert all your “.pde” tabs (w/ the exception of the 1st main tab) to have a “.java” extension instead.

Those classes inside “.java” files will need to import processing.core.PApplet.

And then request the sketch’s PApplet reference on their constructor.

2 Likes
4

Both the answers above are excellent suggestions. Eclipse can be a little finnicky if you’re not used to it, but the kinks are all things that can be Googled easily and it seems like you’re at a point where you can understand the problems that are being solved through proper encapsulation, which will make it much easier to wrap your head around. In general, global state is a really bad thing for exactly the reason you’re finding.

In terms of least amount of effort and workflow changes, as Kevin mentioned you could make all those state variables “public static” but it’d save you a lot of headache in the long run to just make copies in each class you need them and update them as necessary. Having multiple objects regularly accessing the same global variable can get super ugly, especially if you want to start trying to write multithreaded code later on.

2 Likes
5

On the very right next to the tabs is an arrow pointing down which gives you a list of all tabs.

Very convenient

There is also a tool I think that gives you some kind of extra window with tabs list

2 Likes
6

There is – it is called TabManager, and you install it through Contributions Manager and then launch it from the Tools Menu.

It could ease some of the immediate tab pain while thinking about the bigger leap into Eclipse.

Eclipse: For me, personally, I develop libraries in Eclipse and sketches that use that library in PDE. Here is an example of a transition process for a large sketch. At every stage of the process, your complex game demo works (which is important for development with debugging). For a large 2D platformer game sketch, I would

  1. create an empty git repo
  2. copy the Processing Eclipse Library template into it
  3. move my working pde sketch into the Examples and commit
  4. build the (empty) library

Your sketch will be installed in the examples folder of your PDE instance. It is still just your sketch, with a hundred pde tabs – nothing has changed – but now it is wired into an Eclipse editing environment for library development.

  1. include your (empty) library at the top of your Example sketch, rebuild, run in PDE
  2. one at a time, begin migrating your pde tabs out of your example sketch and library classes.
  3. After migrating each class, change your sketch to import it from the library and remove the pde. Recompile and run the example.
  4. Repeat until everything is migrated into the library.
  5. Now you are migrated, and you can begin library development in Eclipse!
7

I thought Eclipse (and other IDEs) wouldn’t be able to compile a sketch until all of its “.pde” files are converted to “.java” 1s. :thinking:

The big advantage to convert “.pde” tabs to “.java” while the sketch is still under the PDE is that we can do it 1 by 1 and the sketch still compiles & runs. :running_man:

Once we are finished turning all “.pde” tabs (except the 1st main 1) to “.java” 1s, we can transfer the sketch folder to another IDE. :arrow_right:

Once there, the only “.pde” file left to be converted to “.java” is the main 1. :coffee:

1 Like
8

Thanks everyone for the replies.

I think the way I’d go around is is to first compile my sketch, then grab the “.java” file that appears in the “sources” folder in the compiled version, make an Eclipse project and throw that file in there, get Processing libraries, and work splitting that out into multiple .java files manually.

The reason is that I didn’t really bother making a lot of classes - in all of these tabs there are only 3 definitions of classes, one of which is unused. I think chopping code into classes manually and encapsulating stuff would be the best approach for the project in the long-run.

Now I’ll have to decide which variables and functions should be in their classes… Sounds like it’s going to be fun.

9

Great, you should definitely take the approach that makes the most sense to you and works best for your project.

A Processing library in eclipse includes an “Examples” folder which just has normal Processing sketches in it. So you can build your library (with Ant) in Eclipse and it will include those PDE sketches copied into the correct place, such that when you install your library, the sketches appear in the Examples > Contributed folder in PDE.

In this way, you can begin with PDE sketches, make them the examples of a library, and migrate their components into the library as you write it.

2 Likes
10

I think I saw somewhere that you are using a linux OS in which case when you run a processing sketch from the ide, the pre-processor spits out the the java to /tmp/####temp folder another to /tmp/####temp for the compiled classes. I have found that a convenient way to quickly dump the java. I use netbeans but I expect eclipse is the same, you have two choices for including processing classes:-

  1. Create a “library” containing the processing jars on your sketchpath
  2. Use maven artefacts (these are unofficial and slightly out of date) but mainly work just fine

Any other libraries you use will also need to be included.

Regarding separating classes there is a tool in netbeans that allows you to refactor inner classes to regular classes (but often needs a bit of manual intervention).

1 Like
11

One of my problems is that I like to change my things a lot, so moving any part of the code(i.e. classes) away from the double-click-and-edit is something I’d love to avoid. And even then, some of these pages contain singular functions that alone have a couple hundred lines of code.

I think I should just rewrite my project from scratch, with occasional copy-pasting of old code into the remake.

Thanks for the suggestion though!

12

IDEs can help you “change your things a lot” :slight_smile: For example you can rename variables and they are renamed everywhere where they are used. They auto import classes if you want. Autocomplete is very powerful.

Maybe the difficult thing is to choose one :slight_smile: Eclipse? NetBeans? Idea?

It takes some time for this new approach to coding to become intuitive. But it actually it can help you a lot in understanding your own programs. If you have tons of variables together in one file, it becomes hard to remember what is needed where. For instance if you delete part of your code, it’s easy that unused variables or methods stick around, and the code slowly rots and becomes unmaintainable. It also happens that there are many parts needing other parts, and you can arrive to such a complex problem that you get stuck, because if you change something, something else breaks. So… just take the step :stuck_out_tongue:

2 Likes
13

Thanks for your reply!
I already settled on Eclipse though - out of all IDEs I don’t know, this is the one I don’t know the least. :v