So I thought I would start a set of guidelines for mod makers to help make an easy to work with mod, both for themselves and for anyone who has the (dis?)pleasure of trying to add to someones work.
The idea of this thread is for modders to critique these guidelines and add there own.
Many sound obvious, but there are plenty of TA mods that don't adhere to a single one. 
Section 1: Overall Unit naming conventions
Having a strong convention that you stick to when naming units is perhaps the most important part of an easy to work on mod. A sidename prefix is particularly useful, and unit names should be a sensible acronym, designation or shortened name.
e.g. ARMWindGen, GERTiger, IMPAT-AT
Section 2: Individual file conventions
by folder:
Download:
Now this may be controversial. The standard way of doing this in TA was to have a unitname.tdf which contained all the places that unit was built. My reccomendation is to switch to having factory_unitname.tdf, which contains all the units built by that factory. This was possible in TA, though in TA download .tdfs could only have a limited number of [MENUENTRYX] (N.B. In TA the X didn't matter, in Spring all X must be different). This makes it easier to spot conflicts and results in less files to navigate.
Also as Spring works its menus differently, it may be simplest to use just one MENU, and constantly increment BUTTON, to avoid menu conflicts. (Of course, the menus may very well work differently in the NewGUI... Indeed I hope blanks are allowed again) So if you would like blanks stick to the TA system.
Features:
All corpses of a unit should be in a single df, sticking to a naming convention. e.g. unitname.tdf, unitname_corpses.tdf Each indvidual feature should also stick to a convention, e.g. unitname_corpse1, unitname_corpse2
Debris is the exception to the rule, as they tend to be used for multiple units, all debris features should be in one f.ex. debris.tdf file.
GameData:
Moveinfo.tdf:
Stick to a convention when naming moveclasses. e.g. LightVehicle2 or MediumVehicle3, where the number denotes footprint. Remember that amphibious moveclasses must have 'HOVER' in their name.
Sidedata.tdf:
Use sensible side names and prefixes
Sound.tdf:
Use sensible categories prefixed by side e.g. GERInfantry, IMPTroops
Objects3d:
All main .3do or .s3o should be named the same as the unit, e.g. ARMWindGen.3do. Corpses should stick to the same convention as used in the features, e.g. unitname_corpse1.s3o
Debris again is the exception and should follow its own convention.
Scripts:
Always. ALWAYS include the original .bos. Descripted .cob have no comments and while Scriptor can guess some obvious variable names, e.g. restore_delay, most it cannot. Which leads me on to...
Stick to good programming style in your scripts - i.e. use sensible, concise but understandable variable names, both static and local. Comment any code which isn't immedietly obvious as to what it does. This will make the life of anyone who is debugging the script later on, including yourself, a whole lot easier. (debugging SWTA transports scripts ripped for AATA from descripted .cobs with ~30 stat_vars is not fun!)
With new units, stick to the Spring style weapon scripts i.e. AimWeapon1, not AimPrimary.
Sounds:
Again, naming is key. Prefix by the category from SOUND.tdf or by f.e.x WEAP for a weapon sound. e.g. US_INF_underattack.wav, US_INF_select1.wav, WEAP_105mm.wav
Unitpics:
Pick a file format and stick to it, and stick to convention e.g. unitname.bmp
Units:
Keep filenames and internal UNITNAME the same (In TA this was actually required, I'm not sure about Spring). Don't miss weapon numbers (this will crash without a NOWEAPON weapon, and they are still displayed in FPS view) i.e. do not have a weapon3 if there is no weapon 2
UnitTextures:
Tatex:
For 3do per-face textures, name the files accordingly e.g. GERTiger_turretfront00.bmp, SIDE_metalgrad1_00.bmp. This makes it alot easier to find what unit is missing textures and where abouts this texture might be on the model.
For .s3o use the same name as your model, for both maps. e.g. GERTiger1.dds, GerTiger2.dds
Weapons:
Prefix weapons by the side that uses them, if multiple sides use the same weapon prefix with f. ex. UNI or ALL. Again use a sensible description e.g. GER150mmH G/H/M would represent Gun/Howitzer/Mortar respecively and indicate the HighTrajectory setting that is appropriate.
One thing to consider would be to place all weapons used by a unit in unitname_weapons.tdf, but this is probably not a good idea; traditonally most weapons are used by more than one unit.
