The answer to this question varies wildly depending on many different factors. Primarily: programming language, type of project, and size of project.
I will give you three drastically different examples to give you an idea of what I mean. Then explain what they have in common.
To start, I need to address an obvious misconception you have about compiled programs.
AronE. wrote:Well, this is the functioning of some GUI component, I will store it in a different file, so that it will be read by the CPU only when its used, and will just stay there, if its not.", ,,Store this here, this one there, because its more efficient." or ,,I will make a new method, just because it is good for the processor..." etc...
Your file structure does not affect the performance of a compiled program. It *can* affect the time it takes to compile the project, but for most small projects there's probably not much point worrying about that. If you really care, you can go read more about compile-time optimization for your specific environment. When you compile a program, all of your code is essentially mushed together into one big binary file; the .exe. Obviously what happens is a bit more complex than "mushed together", but the important thing to know is that files are organized for the benefit of the developer, not the benefit of the computer.
First, let's consider a typical Windows workstation. If you don't use Windows, translate the names and ideas into whatever your OS uses.
You typically have a home directory, on Windows that will be e.g. "C:\Users\Dan\", on Linux it's "\home\dan\", etc. In essence, this is your "root" directory or project directory, if you will.
In this folder you typically have:
Code: Select all
/user/dan
/Documents
/Downloads
/Music
/Pictures
/Videos
Videos go in the "Videos" folder, pictures in "Pictures", music, and downloads in their respective folders. Everything else goes in "Documents" under which you can make further sub-directories at your discretion. The idea is to logically categorize things in a way that makes them easy to find. To give every type of file an obvious, dedicated home.
Now, let's consider a web project. We'll use HTML, CSS, and JavaScript. Whether or not you consider web development "programming" is irrelevant. While specifics change between languages and environments, many of the underlying goals are shared.
In the root folder, you will find HTML files:
Code: Select all
/html
/css
default.css - Contains majority of the stylesheet info for the site
blog.css - Blog-specific styles
/img
banner.png - Website banner used by all pages
dandy.png - "About Me" picture
/lib
jquery.js - The JQuery library (use for fancy blog stuff)
/scripts
blog.js - Custom blog script, depends on JQuery lib, used by blog.html
index.html - Introductory page, requires CSS
blog.html - Simple blog, depends on jquery library and a few custom JavaScript routines and CSS
about.html - About Me page, has a picture of me [dandy.png], requires CSS
links.html - Links to my friends' websites, requires CSS
This structure is fairly straightforward. You can name the folders whatever you want, but it's typically something along these lines. There is no mandatory standard, just be consistent. To key to organization in any project is always to be consistent.
Why are index.html and about.html different files? Because they are different pages of the web site. Why is blog.css separated from default.css? Because it only applies to one page and it's silly to include it everywhere. The more stuff you jam into one file, the harder it becomes to remember where each logical piece of the project resides.
Lastly, let's consider a C++ project. Specifically, and object-oriented organizational approach. As I alluded to above, different languages will have different organizational units.
You're making a simple object-oriented Pong game. Two paddles, a ball, some power-ups, some way to get user input, and some way to render output to the screen. Your organizational structure might look something like:
Code: Select all
/user/Dan/Documents/Projects/SuperPong
/engine
GamePad.cpp - Logic for game pads (e.g. XBox controller)
GamePad.h
Keyboard.cpp - Logic for keyboard input
Keyboard.h
Render.cpp - Logic for rendering game to screen
Render.h
/game
Paddle.cpp - Paddle object
Paddle.h
Ball.cpp - Ball object
Ball.h
PowerUp.cpp - PowerUp object
PowerUp.h
Main.cpp - Entry point, create window and start game
The header (.h) files contain class declarations to be #include'd in other file. The code (.cpp) files contain the actual definitions and logic for the subsystem or object contained therein. The folder structure, again, can be whatever you want. I chose to separate the "engine stuff" from the "game stuff". Sometimes people will make a "headers" folder and put all of their headers there. Sometimes it's all in one big folder.
Hopefully though, you are starting to get an idea of not only why folder structure is important, but what sorts of things are organizational units. A "paddle" and a "power-up" are two completely different organizational units. So we separate them into different files. Both are part of the Pong game, which is why they're both in this project directory, but that doesn't mean they should be in the same file. Likewise, just because a ball interacts with a paddle, doesn't mean they are part of the same organizational unit.
If you'd like to provide more details about your environment, your language choice, and your project, then we can talk more specifically about how you might apply these ideas to your own code.
As always, if you have any questions please post them here and I'll do my best to answer them.