Single folder source vs. foldered

[Baker]

Some Quake engines have their source code organized into specific folders.

Some use one folder for everything.

DarkPlaces: single folder. GLQuake: single folder. FTEQW and FitzQuake SDL: multiple folders.

I personally prefer the single folder approach because it makes it easier for WinMerge to sort out changes I've made.

On the other hand, if an engine has multiple operating system folders I can quickly peek into the MAC OS X folder and assess what I need to think about dealing with that is operating system specific. (FitzQuake SDL is an example).

I've got about 15 builds of my engine now and in my opinion it is nearly impossible to come up with a consistent way to cleanly put stuff in different folders.

Side topics: Folder usage in source codes, you end up having to 'include "..\whatever.h"' alter relative paths to headers.

Anyway: a month or 2 ago I was sitting on the fence on the issue and opened up DarkPlaces source and I often use what LordHavoc does as a tiebreaker (I'm sure he thought about the issue once upon a time and came to a reasoned conclusion.) and DarkPlaces uses a single folder for everything.

[mh]

I prefer a single folder for everything. Relative paths for include files, having to move things around to keep stuff organised and so on becomes messy otherwise; there is a point at which the semblance of "organisation" actually becomes overhead and burden.

But I'm not religious on the matter; it's just the way I like to work and I do it for reasons that are right for me. Others may prefer different for reasons that are right for them, and that's cool.

[andrewj]

I just reorganised my Quake2 port to use a single folder, instead of the multiple folders of the original code. That's because I'm using Linux and command-line tools (ls and grep) are more convienent to use with a single folder.

The Quake2 arrangement was decent though, worthy of copying if you were to go the other way and multi-folderize the Quake code.

Oh yeah, if you want portable code then you should use / instead of \ in #include filenames

[Spike]

if your filenames carry some sort of prefix for their area of the engine, then it doesn't really make any difference at all.
the annoying thing with fte's code layout is that server things are no longer server only (due to csqc) and gl things are no longer gl only (due to d3d/general format support in servers). a lot of files ought to be renamed/moved in fte.
tbh, if it can be considered a separate and individual project/module, it should have a different directory, otherwise not.
obviously fte violate that. :)
but yeah, keep your libs and project files separate from the source and you're slightly better off next time visual stupio decides to delete all your files because they look like they ought to be temporary files anyway, despite being named foo.c
die msvc, die.
but yeah, independant modules, independant dirs, otherwise you find you need to use -r when using grep, and that's just extra typing

[frag.machine]

It's good to have some way to quickly identify a subsystem into the project (say, audio or network). As commented, folders may add burden when using tools like grep or diff, so maybe the use of a name prefix (sys_*, snd_*, net_*, etc) sounds like a better idea. OTOH may be wise to keep a different folder for third party libraries and their headers so you can easily handle your own code apart from the dependencies (specially in the case of cross platform projects).

[mh]

I've actually changed tack a little and have come to like organising code into subsystems within the IDE itself, but they don't necessarily need to correspond to folders in the filesystem. Don't need grep when I've got Ctrl-Shift-F (and Ctrl-Shift-H).

[Baker]

if your filenames carry some sort of prefix for their area of the engine, then it doesn't really make any difference at all.
the annoying thing with fte's code layout is that server things are no longer server only (due to csqc) and gl things are no longer gl only (due to d3d/general format support in servers). a lot of files ought to be renamed/moved in fte.

You know, this gets into the separate source file versus #ifdef issue. #ifdefs are awesome but suck at the same time. I've accumulated a bit too many as of lately and am seeking to simplify.

It's good to have some way to quickly identify a subsystem into the project (say, audio or network). As commented, folders may add burden when using tools like grep or diff, so maybe the use of a name prefix (sys_*, snd_*, net_*, etc)

Actually, I've renamed all my source files. sys_ ? snd_? net_? cl_? Those names were because 8.3 file systems needed short abbreviated names. I keep forgetting what certain rarely touched source files were for and finally decided to rename all of them.

r_part.c ? Although a bad example maybe in the sense that file gets used all the time, the r_ prefix implies it for the software renderer only.

At first, I thought about not renaming all the file names. But on further consideration, I came to the conclusion that really after get significantly far away from the id1 source code, someone very new isn't going to be able to understand the code quickly and someone experienced will still know what is going on. So there isn't much benefit to keeping the old abbreviated names.

But yeah, that's what I did.

IOh yeah, if you want portable code then you should use / instead of \ in #include filenames

I typed it wrong was but thinking it right ... otherwise I'd have a great deal of trouble to get it compile, you'd think.

[Sajt]

An annoying thing about MSVC is that it puts all compiled .obj files in the same output directory. So if you have renderer_sw/world.c and renderer_gl/world.c, one will end up overwriting the other in Debug/world.c and the build will fail. This really (really) annoys me, and I'm not sure how to fix it other than manually specify an .obj path for every single source file in the project, which is silly.

[Baker]

An annoying thing about MSVC is that it puts all compiled .obj files in the same output directory. So if you have renderer_sw/world.c and renderer_gl/world.c, one will end up overwriting the other in Debug/world.c and the build will fail. This really (really) annoys me, and I'm not sure how to fix it other than manually specify an .obj path for every single source file in the project, which is silly.

Interesting. Thanks for info.

[Feared]

Folders.
Every source file in one directory is just plain out ugly and annoying to work with. It's all preference, though. I personally enjoy folders, my self.

Granted, after adding so much to an engine then wanting to clean up code. That sounds like a huge pain in the ass with little gain. I'd say if you're starting an engine then clean it up in the beginning/start of the project.

[Sajt]

Anyway: a month or 2 ago I was sitting on the fence on the issue and opened up DarkPlaces source and I often use what LordHavoc does as a tiebreaker (I'm sure he thought about the issue once upon a time and came to a reasoned conclusion.) and DarkPlaces uses a single folder for everything.

Also, don't be so sure about this. Sometimes the rationale for avoiding such changes is to avoid taking a big crap on the version history. (Same with not unifying code style.)

I'm not saying he didn't decide it was the best idea though. I'm definitely gravitating toward everything in one folder, using filename prefixes to arrange them nicely, unless one's project is some C++ thing with thousands of tiny source files.

[qbism]

Forget folders, Berserker Q2 puts the code in one FILE. A single file for the engine code, and a single file for the game code. Set up some bookmarks in VC++ and experience a certain freedom.

[Spike]

A single file means you get better optimisations/inlining... Means you're not endlessly compiling windows.h over and over again... Ensures your prototypes _always_ match your functions...
Can't complain! :P

[Feared]

A single file means you get better optimisations/inlining... Means you're not endlessly compiling windows.h over and over again... Ensures your prototypes _always_ match your functions...
Can't complain!

Yeah but when the file takes a bit to just load, damn that's a problem. This is not healthy programming, either.

[mh]

I used to write code like that...


...in 1989 when I was learning COBOL!!!