This concept can and is recommended for any platform, however, I will be using mac as I just setup a new dev environment on a MacBook Pro (💪). I mostly work with JavaScript projects so I may not have run into issues that a more polyglot programmer might run into, but if you have suggestions on basic directory structure, let me know.

The first thing you need to do is find out where your development directories are going to reside. For instance, on my PC, I put them on the root of theC:\ drive in a directory calledC:/dev, but on my Mac, it's in theUsers/[username] directory. This is the same directory that is defaulted to when you open your terminal, as you can see here I have placed mydev folder inside that directory.

Once you have figured out where this folder will reside on your machine, it doesn't matter what platform you are on, it's all just organization of files and folders from here. What I'm about to explain may seem trivial to some, also understand that I am not trying to enforce this as a best practice (although some developer communities like GoLang have a similar approach). I went years without a consistent approach to how I organize my projects and applications and at the very least this would have saved me a lot of time and grief over time. You can always tweak and make changes and rules as you need to, but the idea is that you are better off with at least some consistency at this level and if we are just talking about directory structure, there is not many rules that need to be followed.

Let's look at how I organize this dev directory, anddev is just the name I used, you could call this whatever you want, some usecode orprojects but I like dev because it seems a little more generic, and outside of thesrc directory I can add directories likesandbox and whatever fits into my development category. I have a few rules that I will state up front that I follow, especially in thesrc directory.

• all directories are lowercase
• all directories are kebab case (that I can control)
• there is a directory namedsrc
• src contains a directory for each git platform
• inside each git platform is only repo names

These rules are the most important for me because they define a convention for how mysrc directory will be laid out and those rules define how I will create and name project folders, but I also like to extend this convention to all folders within thedev directory if possible. There are some cases where I cannot follow these rules for instance, if I clone a repo that is not mine, but I try to set standards for my own projects or my teams projects. I have taken cues from the GoLang Code organization and workspace standards. This is one community that I tend to agree with although my naming conventions are my own.

GoLang - Code organization

This guide is just one that covers the very basics of "how are my projects stored in a directory hierarchy" and "how are those root level folders for each project (that become git repos in most cases) named". That's it.

Coding styles and naming conventions of classes, functions, methods properties and all that jazz are not part of this recommendation mostly because those are team and project specific. If I have a GoLang project and a JavaScript project repo and one is open source and another is a project that I work on with my team, these could have very different conventions being followed. This guide as I said ends at the root level folder for each git repo and is just a convention for storing those repos in a hierarchy.

Inside mydev/src directory you would see all of the different git-based repository hosting platforms that I store code in:

Let's take a deeper look into repos that come from my GitHub. If I were tocd into mydev/src/github/httpjunkie directory (notice folder names are all lower case), it would look very similar to what you would see onmy GitHub account. These are all of the repos (public or private) that I have on my computer at the time. It does not have to be a full representation, I don't ever have every single repo from my GitHub on my machine at any given time, just those that I am actively working on or hav previously cloned.