[nergal]

I often find myself making big plugins and I want to reorganize the code into multiple files but I find it difficult how to reorganize them...

How can I reorganize a single huge plugin into multiple files?

[ClassicGuzzi]

It depends of what the plugin does. If the plugin has stock functions like IsValidClient for example but A LOT of them you could move them to an include file (unless they use global variables form the plugin).

If you really want to separate in multiple files you have to keep in mind that, either those other plugins won't have functions directly related to the main plugin, or you are going to use a "core" plugin with natives to communicate with other plugins, with you only should do it if you want a flexible and modular plugin.

[Powerlord]

You can split a plugin into separate files without turning it into separate plugins.

For example in NativeVotes:

• nativevotes.sp has the core functionality of the plugin plus its natives
• nativevotes/data-keyvalues.sp has all the things for manipulating a vote handle "owned" by NativeVotes (its named data-keyvalues because the backing store may change later)
• nativevotes/game.sp has functions for individual games that NativeVotes supports as well as Game_ abstract functions that determines which function to call for which game.

That's just an example and your plugin may be done differently. basevotes is another plugin to take a look at as it consists of basevotes.sp and a separate sp file for each vote type is supports.

[nergal]

Originally Posted by ClassicGuzzi It depends of what the plugin does. If the plugin has stock functions like IsValidClient for example but A LOT of them you could move them to an include file (unless they use global variables form the plugin). If you really want to separate in multiple files you have to keep in mind that, either those other plugins won't have functions directly related to the main plugin, or you are going to use a "core" plugin with natives to communicate with other plugins, with you only should do it if you want a flexible and modular plugin.

Well I DON'T want to use natives, that's why I'm asking how I can reorganize a huge plugin into multiple files to later all compile into 1 file.

I've been reading tutorials on C++ that talk about how to organize a project into multiple files.

But it feels clunky and difficult trying that with Sourcepawn (Yes I know they're 2 different languages xD)

Which is why I'm asking if there's a way to organize a huge plugin so that it'll work just fine when compiled from multiple files.

I'm pretty sure the issue with this is from having global variables but is there a way?

[ClassicGuzzi]

As powerlord said, you could separate them into multiples .sp and include them at the beginning of your main file, like #include "nativevotes/data-keyvalues.sp"

Every global declared on that file will be accessible on your main file.

[nergal]

Originally Posted by ClassicGuzzi As powerlord said, you could separate them into multiples .sp and include them at the beginning of your main file, like #include "nativevotes/data-keyvalues.sp" Every global declared on that file will be accessible on your main file.

One C++ tutorial on Organization actually helped me out.

it said to split up code based on "responsibility/function" of each code

class and struct definitions, typedefs, global variables, constants, #defined macros, #pragma directives, and stocks all go into the .inc file while code in the .sp is split down for each action every part of the code does.

Through that rule, I was able to break up my plugin into 3 .inc files for defs, globals, and stocks and 7 .sp files not counting the core to compile them all against.

I think I'll post a tutorial in the tutorial section.

[ClassicGuzzi]

Originally Posted by nergal One C++ tutorial on Organization actually helped me out. it said to split up code based on "responsibility/function" of each code class and struct definitions, typedefs, global variables, constants, #defined macros, #pragma directives, and stocks all go into the .inc file while code in the .sp is split down for each action every part of the code does. Through that rule, I was able to break up my plugin into 3 .inc files for defs, globals, and stocks and 7 .sp files not counting the core to compile them all against.

I should do that with my dodgeball plugin now that you mentioned it.

By the way, I don't know on which plugin are you going to do this, but you could also start changing things to the new 1.7 syntax while you are in it

[nergal]

Originally Posted by ClassicGuzzi I should do that with my dodgeball plugin now that you mentioned it. By the way, I don't know on which plugin are you going to do this, but you could also start changing things to the new 1.7 syntax while you are in it

I've used the 1.7 syntax when it was still development phase

[Chdata]

#include "file.sp"