[nergal]

You might think "why is there a tutorial on such a simple task?"

Answer: many people who code on SourceMod are also first-time coders with no prior experience.

This tutorial aims to help those same beginners by helping them professionally organize their code to be more readable, easier to edit and debug, and look professional and presentable.

For the purpose of this tutorial, I will be using a public plugin (SaxtonHale plugin) as an example!

This is the latest, as of March 6, 2015, code for the VSH plugin - https://github.com/WildCard65/Versus...emod/scripting

As you could see, it's GHASTLY large... About 8k+ lines to be exact.

To start organizing, I should cover that the most commonly used organizing technique is to separate the code according to the responsibility of each portion of code. Separate the code based on what part does what exactly.

A good example, to start with, in the VSH code would be to place classes/structs, typedefs, enums, global variables, constants, #defined macros, #pragma directives, and stocks into their own include files.

In the case of the VSH code, the enums and defines could be in their own "defs.inc" while globals in their own "globals.inc" and stocks in their own "stocks.inc"

NOTE: static variables cannot go from file to file, so please remember this if you're using static globals...

From how I personally organize code, I was able to organize the entire VSH plugin into 21 different files to all be compiled into a single plugin (pic below).

it should also be noted that additional features added to SourcePAWN could impact how to organize code such as the addition of structs would reduce/eliminate the use of global variables.

As for the rest of the code, this is where the "sort by responsibility" discipline take place in effect.

Firstly, look at how you would split your code into sections. Often this is by splitting it into separate subsystems, or 'modules', such as autocalled functions, hooks, functions that deal with clients, etc.

Create new files with meaningful filenames so that you know at a glance what type of code is in them and simply move all the code into that file.

There can still be other criteria you use for splitting up code, such as the structure it operates upon or your own design of the overall plugin.

("general purpose" functions can be split into string-handling and number-handling, for example if they're not stocks) And occasionally a module could be split into two or more files, because it might make sense to do so on logical grounds.

EDIT: Please remember that this tutorial/instruction should only be used on code that is well over 1,000+ lines. Having code that large makes more sense broken up for easier everything.

[WildCard65]

hmm I may actually do that for 1.7 port of vsh

[nergal]

Originally Posted by WildCard65 hmm I may actually do that for 1.7 port of vsh

you don't have to, I was just using it as an example ( ͡° ͜ʖ ͡°)

[WildCard65]

Well, try porting 8000 lines of code over to pure 1.7 syntax. Not even 50% done yet.

[nergal]

Originally Posted by WildCard65 Well, try porting 8000 lines of code over to pure 1.7 syntax. Not even 50% done yet.

I did that in 2 minutes

first replace ALL with
"new Float:" -> "float "
"new bool:" -> "bool "
"decl String:" -> "char "
"new String:" -> "char "
"new Handle:" -> "Handle "
"Action:" -> "Action "
Then finally, "new" -> "int"

That part handles the variable declarations, for function parameters...

"&Handle:" -> "Handle &"
so on with the referenced variables.

Strings must be turned to char manually though along with int being added to the ints.

The rest to use methodmaps should take the rest of the time.

[aexi0n]

Quick Question. So my plugin is written with about 8 different files currently, and uses natives for needed information from each other. I'm trying to optimize the code completely, and make it so I have "myplugin_main", and include the other files such as "myplugin_hooks", "myplugin_commands", etc.

I've got this all working fine, but I have a question regarding which variables are usable. I know that the file "myplugin_main" will have access to all global vars from any of the other files it includes.

But in an included such as "myplugin_hooks", would I be able to use a global variable from another include file such as "myplugin_commands"

If so, is there some special way to do this? Can't seem to figure it out.

[nergal]

Originally Posted by aexi0n Quick Question. So my plugin is written with about 8 different files currently, and uses natives for needed information from each other. I'm trying to optimize the code completely, and make it so I have "myplugin_main", and include the other files such as "myplugin_hooks", "myplugin_commands", etc. I've got this all working fine, but I have a question regarding which variables are usable. I know that the file "myplugin_main" will have access to all global vars from any of the other files it includes. But in an included such as "myplugin_hooks", would I be able to use a global variable from another include file such as "myplugin_commands" If so, is there some special way to do this? Can't seem to figure it out.

Why aren't your globals all in one include?

If you want a global variable modified by your entire plugin, u might as well compile your plugin with your globals being in one single file to be used by the rest of it.

If you're not going to use globals in each respective file, you have to use local variables or functions that modify and sent data to and fro.

[Powerlord]

Not sure a tutorial is appropriate for this topic.

Different coders may prefer different styles of dividing up functionality in different files.

People who do a lot of OO programming may organize it differently than this, for example.

[nergal]

Originally Posted by Powerlord Not sure a tutorial is appropriate for this topic. Different coders may prefer different styles of dividing up functionality in different files. People who do a lot of OO programming may organize it differently than this, for example.

I know about that but this tutorial is just meant for beginners.

You're too pro to be a beginner, leave

[asherkin]

While a good way to clean up an existing plugin, for a greenfield project you should really split by functionality rather than type.