How do you structure your source code?

Question

(I'm asking this with Visual Studio Web Applications in mind, but am interested in more high-concept answers)

Recent topic of conversation in my life with colleagues and friends has been how best to structure source files within a project. Not a source-control question or a development-environment question per se, I'm more interested in how people choose to group, name or otherwise manage their projects.

The way I'm working right now is based on a ruleset.

• web.config + global.asax at the root
• web surface pages at the root
• deeper web content in appropriately nested folders
• resource files (css, js, images, transforms, error pages, config) in a "resources" directory then nested by type
• non-codebehind classes in namespace appropriate folders prefixed with an underscore (so they are grouped at the top of VS's project explorer)
• generic utilities (config reader, xslt manager, DAL) in a "_utils" folder.
• abstract classes also prefixed with an underscore (so they are grouped at the top of a folder)

Unfortunately this has broken a bit since I introduced unit-testing and interfaces to the company, and all too often results in a ubiquitous "businessobjects" namespace, hence the conversation/debate/sulk :)

So how do you handle this? I've heard of teams who create "Interface" folders, who create a folder for each custom object base-class, or even who dump all the code in the root and prefix filenames ($ for structs, "C" for classes, "A" for abstracts). Obviously what works for one project type won't necessarily for another, but are there best-practices common to all?

Answer 1

At work, we generally follow the advice given here:

How To: Structure ASP.NET Applications in Visual Studio Team Foundation Server

Answer 2

I think the answer greatly depends on the environment you are using as a programmer.

In java world, the Maven Standard Directory Layout is fairly widespread and I'd say quite reasonable way to organize your source.

Although - when working in teams, the actual project layout is something that is mandated by the team any way and most of the time it is at least source in /src or /src/java, and resources in /resources, and build results in /build/classes, /build/target/, etc.

Answer 3

Well, this is just a personal take on it.

I prefer to organize code (and directories) in such a way as to minimize the effort of making the kinds of changes that can be anticipated. Often this might not be considered "pretty". Form should follow function.

For example:

I've seen people say: let's have one directory for mainline code, another for data structure classes, another for UI code, another for UI resources, and yet another for XML (say). That is organizing by the type or function of the file. By that method, if you make a change in your schema, there are many files in many directories that need corresponding changes.

I can anticipate that there will be changes in the schema/class/data structure. Therefore, for each persistent data class (say) all the code that would have to be changed when that class is changed are near-by and easy to find, to simplify the process of making all the changes.

I think OOP itself is essentially an attempt to do this. Before OOP, data structure changes required multiple synchronized edits distributed throughout the system. Now with OOP, it is still possible to distribute source code dependencies widely, and I think that battle still needs to be waged.

No such scheme should be considered dogma. (Heaven knows there's anough of that in this field.) It's a matter of using common sense.

Answer 4

In this post I show how I usually structure my source code repository http://thegsharp.wordpress.com/2009/09/05/structuring-your-source-code/. Cheers!

Answer 5

As long as the development environment doesn't impose a certain structure I always try to follow the same principles as with the code itself and try to achive the highest level of cohesion.

Answer 6

@Mike Dunlavey

Mike AOP is aspect oriented programming, and among other things tries to keep concerns seperated. By keeping concerns seperated the code (and files) of a specific concern should be kept together. There's a very interesting approach to this which tries to seperate concerns through use cases. You can find more information about this in the book "Aspect Oriented Software Development with use cases" by Ivar Jacobson and Pan-wei NG.

Cheers! Gus