You can assign a package prefix to a source root (e.g.com.mycompany.myapp)
instead of creating the corresponding folder structure within that source root
(e.g.com/mycompany/myapp). For more information, see Package prefix for Java source roots.

In the absence of the package prefix and the subfolders,
a source root would represent the default package (an unnamed package).

Generated source roots
(or generated source folders; shown as ;
in certain views the
[generated]
text marker is used) are similar to source roots.
The difference is that the generated source roots are not suggested as target folders
when performing the
Move Class refactoring
or
using the Create Class from Usage quick fix.

Test source roots
(or test source folders; shown as ).

These roots are similar to source roots
but are for code intended for testing (e.g. for unit tests).
Test source folders let you keep the code related to testing separate from the production code.

Compilation results for sources and test sources, normally, are
placed into different folders.

Generated test source roots
(or generated test source folders; shown as ;
in certain views the
[generated]
text marker is used) are similar to test source roots.
The difference is the same as between the source roots and the generated source roots.

Resource roots
(or resource folders;
shown as ; available only in Java modules) are for
resource files used in your application (images, various configuration XML and properties files, etc.).

During the build process, all the contents of the resource folders are copied to the output folder
as is.

Similarly to sources, you can specify that your resources are generated.
You can also specify which folder within the output folder your resources should be copied to.

Test resource roots
(or test resource folders; shown as ;
available only in Java modules) are for resource files associated with your test sources.
In all other respects, these folders are similar to resource folders.

Very limited coding assistance is provided for files in excluded folders.
Classes contained in excluded folders don't appear in code completion suggestion lists,
references to such classes are shown in the editor as unresolved.
When searching, IntelliJ IDEA doesn't look in excluded folders, etc.

Making the folders whose contents are "less important" excluded may improve the IDE performance.

Normally excluded are compilation output folders.

Modules without content roots: Collections of dependencies

A module can be used solely as a collection of dependencies for other modules.
In such cases, instead of specifying the necessary dependencies separately,
you can add the dependency on the corresponding module.

A module used for such purpose, obviously, doesn't need a content root.

Package prefix for Java source roots

A package prefix specifies which Java package corresponds to a folder and
can be assigned to the following categories of the Java source roots:

Sources

Generated sources

Test sources

Generated test sources

If specified, the package prefix acts as an equivalent of the corresponding folder structure which
has to be created otherwise.

To illustrate, let's assume you are going to work with the com.mycompany.myapp package.
In the absence of the package prefix,
you would create the folder structure com/mycompany/myapp
in the corresponding source root folder (e.g. src).

The alternative would be to assign com.mycompany.myapp to src as its package prefix and
store the corresponding classes right in src.