[drekes]

I'm planning on starting a new big plugin very soon
but i've already stopped some ideas in the past because the code was too unorganized.

Usually i would split everything in seperate files according to the type of function like:

stocks.inl
forwards.inl
events.inl
const.inl
etc...

but that requires you to compile locally which seems to be a problem to many people.

So i was wondering if you guys have some tips on keeping a code organized & clean.

[nikhilgupta345]

Usually it's only compiling locally while it's in new plugin submissions, and then a moderator would put up a compiled version to use. If you really don't want to use that, I guess you could have separate parts in the file, with like commented breaks.

So whatever you would put in stocks.inl, put at some part of the file, forwards.inl ,another part of the file, etc...

[drekes]

Do you use a certain order for your functions ?
Or do you make it like the function are in the order that they are called ?

What do you think would be the easiest to maintain ?

[nikhilgupta345]

What I usually do is keep the Ham_ functions together, then the FM_ functions together, the Event_ functions together and the LogEvent_ functions together.

The order of which comes first (Ham, FM, Event, LogEvent) depends on which order they are registered in plugin_init.

[drekes]

Nice idea, gonna use that for sure.

[Xalus]

What does .inl means?

[nikhilgupta345]

It's another form of include files.

So you would just do basically #include "stocks.inl"

or if your .inl files are in a different folder
#include "folder/stocks.inl"

It allows you to use all the functions located in those files.

Also, if you have one for forwards, (forwards.inl), you can put all your functions that are hooked in that file, and they will still be called if registered from the main plugin.

Just makes it easier to organize.

If you want some examples, look at war3ft or pokemod.

[DarkGod]

.inl = inline, if I'm not completely mistaken. :p

[abdul-rehman]

Or you could make seperate plugins which interact with each other, and each plugin would handle a specific feature
You can see this idea has been implemented in ZP 5.0

[nikhilgupta345]

Originally Posted by abdul-rehman Or you could make seperate plugins which interact with each other, and each plugin would handle a specific feature You can see this idea has been implemented in ZP 5.0

That would require natives, and natives are slower than just keeping everything together. ZP does that just so it's easier for players to turn off/on features, and because it was re-created so that it would be a main core plugin, and everything else would be addons.