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.