Basically what I would like to know is, when you are laying out your code thoughts, how do you organize your Functions and Procedures in your code.

Do You list them alphabetically ? Why ?

Do You group them together based on what they are doing ? For Example do you group are your math routines together ? Why

Do you list them based upon their chronological order of use in your code ? < I realize in main() that it has to be this way, I am more interested in the Functions and Procedures >

What about you user input files that you save, such as a "SAVE GAME" file. How do you organize the output.

I am curious on your thought process and why you chose to do it they way you do.

I'm perhaps a bit old school but I don't intentionally organize functions in any particular way. And (you might have seen this coming) it depends on your coding style and experience.

The general approach, though, is based on keeping the scope of each function reasonable. Don't do too much in any one function. The primary benefit of that is you'll find you can reuse a lot of the code you write.

If I've previously coded a similar task, and I want to code a class for that task, I start with the class declaration, pretty much just listing functions I know I'll need. I may "group" Get/Set functions together, but that's pretty much the start. For the function definitions, I may start at the end - that is, write the code that determines the final product for the task. Then I work my way backward from that, supplying helper functions to get information in the form needed for the final product.

If the task is relatively new to me, most often I start at the end - to determine what's needed to create the "output." The final product for the task may be as simple as "output-matrix = this-matrix times that-matrix." I then figure out how to construct "this-matrix" and how to construct "that-matrix." That process works backwards until I get to the input for the task. That process works (for me) if I have the luxury of defining what inputs are required. If the inputs are fixed, i.e., the task is to use something specific to produce the final product, you should know ahead of time that it's possible to do that.

Being basically lazy, I then compile the code to get all the error messages telling me this or that function is not a member of the class, and I add the declarations.

i use non OO procedural c++ syntax, so what calls what determines the order of appearance in the source code. other than that, i clump related data structures and functions into abstract data types - resulting in something very similar to an object - data structures and the code that operates on them, with a well defined API for accessing the data structures.

savegames are basically a core dump of the entire game state. so they usually start out by saving all data structures in the order they appear, or most important to least important. then as new features are added, these are appended to the end of the load and save routines.

I make a sketch design first, thinking about main subjects that my code will have.
This will be my namespaces, i.e for my engine: IO, audio, renderer, d3drenderer, etc.
Then I just start and follow the consistency within the namespaces, which might change during time if I didn't think of something.

On coding style I have my own guidelines/ principles:
- be const correct when adding stuff
- make class members private as a base, create get...() functions to retrieve values
- in my classes prototypes and implementations non const functions first, followed by the const ones
- every function implementation has 2 commented lines above, one about it's goal and the other one about what it does/ returns
- don't pass around stuff when you can use const ref
- only develop what I need for, no "set...." functions for private members when i don't need them at the moment
- error handling everywhere
- .... Etc

I also have a always 100% updated XLS file as code documentation, one line per function. With columns about what's returned, passed, const yes/no etc. Keeping this updated triggers me to once in a while easily improve my codebase, consistency etc.

On data files and filenames, I name headers of a class the same as the class. For example my application (engine) would be called myengine, then the class d3drenderer would be defined in "myengine_d3drenderer.h" etc. This saves lots of time when trying to find specific things.

And no, I don't have OCD :)

in my case, things are organized recursively roughly by category, for example:

renderer

world rendering

lighting / shadows / ...

rendering voxel terrain

3d character models

texture and shader / material management

...

game logic / server-side logic

entities / AI

physics

world stuff

player stuff

...

client-side / input-handling / UI

common

world loading/management stuff

voxel terrain stuff

console related stuff (processing commands, cvars, ...)

stuff for image-processing and video data / codecs / ...

stuff for audio-processing (sound effects, mixing, ...)

assorted math stuff

vector and matrix functions

primitive types (AABB / OBB / ... collision-checking, ...)

things like polygon clipping and similar (clip triangle by plane, ...).

infrastructure

virtual file-system

memory manager / GC

dynamic type and object facilities

script VM VM / interpreter

...

within this, things may be broken up into specific topics, for example, within image and video stuff, there might be files or groups of files dedicated to specific image formats or codecs, as well as specific data representations (stuff related to DXT5 or BC7, for example).

however, there may be some amount of overlap, for example, several formats may share things like the DCT / IDCT transforms, as well as a lot of special case-code, such as YCbCr 4:2:0 (or YCbCrA 4:2:0:4) to DXT5 or BC7 conversion logic.

but, this may be kept separate from the renderer, which may just be like "give me those video frames as BC7", and may not really care how the video-decoder stuff does so (or all the hair that goes into real-time BC7 transcoding, or its quality limitations, ...). likewise, the video-codec logic may not need to care about the specifics of how the texture-manager streams stuff to the GPU (PBOs vs glCompressedTexImage2D calls vs ...), its main goal just being to fill the buffers quickly. likewise, the video-codec may have some stuff otherwise irrelevant to the renderer, such as logic to allow it to be callable from VfW or DShow or plug into VLC, ...

beyond this, generally things are organized by similarity.

for example:

BCn stuff

DXT5 stuff

whatever -> DXT5 block-level conversion

variants based on input format (RGBA, BGRA, YUV420, ...)

variants based on secondary requirements

slower but higher quality (such as for texture loading)

faster but lower quality (such as for video playback)

DXT5 -> whatever (have DXT5, need RGBA, BGRA, or YUV420 or YUV422, for example)

image-level functions (convert a whole image, flip image, or convert+flip, ...)

...

BC7 stuff

like above, but all over again for BC7...

BC6H stuff

likewise, but for floating-point textures...

...

so, one might end up with a source file dedicated to various "whatever to DXT5" conversion functions, another for "whatever to BC7 mode 5", ...

elsewhere in the engine, it may be a different set of files dedicated to each specific enemy type (enemy-specific behaviors and animations, ...).

or, in an interpreter, files dedicated to various arithmetic operators or array load/store operations or field get/set operators, ... (because we might need versions of the operators specific to various operand types, ...).

a lot of this is not necessarily because anything is particularly difficult, but mostly because of performance constraints and special cases and variations, which may in turn sometimes result in a lot of hair and bulk.