Ask HN: How do you organize your code on your machine?
Currently I have a Code directory which is littered with all sorts of stuff and in general is pretty unorganized. Between small code snippets and fully-fledged projects, the whole directory is a complete mess.
So, how do you organize your code?
51 comments
[ 2.9 ms ] story [ 115 ms ] threadhttp://breckyunits.com/code/how_i_organize_my_dropbox
'sandbox' is organised by language, with code snippets and small projects in each folder. If anything becomes of the small projects they migrate to the 'projects' folder. Anything in the projects folder means it must be in a repository, git or svn.
Working copies, demo code, samples, etc of dependencies of my projects are kept separate to avoid polluting my backups with stuff that isn't mine.
When learning a new language or framework, I consider it the same as a project and make a corresponding folder. Good to keep learning material, notes, project Euler snippets, etc.
Random snippets, quines that print sierpinski's gasket, and other useless stuff goes into the "Snippets" folder.
Each project gets its own directory that contains everything needed for that project (unless I have a shared framework, library, etc). All the projects are committed to a private SVN repository although I am taking a serious look at Git lately.
I might consider moving them all to using gists, but I'm not quite sure if that's ideal.
Sandbox: Contains code i'm working on or projects that i still consider active. Some of them i've converted to github.
Archived: Contains old projects or code, that are inactive, or somethings that are not on my plate in the near future.
For code snippets you might use gist on github, but i tend to use onenote. I have a queries notebook open on MS Onenote, and anytime i google search some new snippet, troubleshoot advice, configuration detail etc, it goes that notebook, with keyword tags.
Everything else is in my svn repo that I can access from anywhere with svn+ssh.
Recently, I've started putting code spippets that I think I will re-use in my Dropbox.
~/svn/ is where I throw my SVN checkouts (sometimes google code stuff, but mainly just python trunk until it gets fully hg'd)
~/scratch/ is where I create subdirectories for my quick-and-dirty scripts, or if I need to `cat` something somewhere real quickly.
~/sandbox/${vcs}-sandbox/${project}/
I'm thinking about removing the ${vcs} level though since I've got over 50 projects in 5 different VCS directories and it's getting hard to remember which vcs each one is in.
Some of these subdirectories are actually symlinks to encrypted DMGs, again depending on who owns the IP.
Project is the top level checkout of the projects.. My 'asf' (aka Apache Software Foundation) directory contains 84 project level checkouts.
I also keep a ~/work/temp directory full of random source tarballs if I need to look at how something works. Currently contains glibc, python 2.6 & 3.1, dojo, and about 30 other open source projects, normally ones I'm not normally involved in patching, but often run into... difficulties with. Nothing resolves bad documentation quicker than looking at the source code...
I tend to nuke temp once every 6 months.
That is how I handle customer proprietary data also for customers who want their work encrypted.
IE:
~/code/@asf/httpd-dev ~/code/@asf/hadoop-trunk ~/code/@linux/linux ~/code/@linux/git
The @ symbol will sort the grouped directories first when sorted by alphabetical.
I also have ~/tmp, which is where I put things I'm unlikely to need more than once or twice. Keeps my desktop clear and my projects folder uncluttered.
Tarballs go in ~/proj/v/
currently : master git repository for everything, something like ~/docs lots of breakdown of documentation more git repositories under : ~/docs/code/projects - stuff I am currently working on or using ~/docs/code/legacy_projects - stuff that I don't want to die or need for reference, but I've lost interest for one reason or another ~/docs/code/public_projects - mirrors of servers, portfolio pieces, videos, all sorts of things that other people can see
I've been flirting with mavenizing everything for some time, but I just can't seem to overcome the inertia of... current build process works, code needs to be written, deal with it later
~/workspace/perl ~/workspace/erlang ~/workspace/cpp
Then inside each folder there is a project. And I either create them or import them using eclipse.
For projects that are large and require a large number of languages. I simply create it under the workspace directory. (i.e. ~/workspace/MyBigProject)
And from then I break it down into languages again along with other folder necessary for larger projects.
MyBigProject -> bin/ conf/ docs/ erlang/ perl/ sql/ web/
Then I tend to use the best possible layout for a project of that language. For example since I use CGI::Application a lot using perl, my perl folder uses the following structure:
and so on, the same goes for the erlang OTP: and MyBigProject/web just holds all the html/javascript/css files for the WebUI.And so on.
~/extern-projects : where i pull other projects from github and stuff, just to mess around with / bugfixes
~/src : where I store little scripts or test code, just a sandbox area to mess around.
~/test : i send testing tarballs here, basically anything I don't care too much about, as I empty this folder out periodically.
~/projects/package-gen/dst/PROJECT — my personal projects in RPM package format, with automatic build system, various templates for new packages, repository of built binary and source packages;
~/work/PROJECT — work;
~/bin — various personal scripts and programs;
~/tmp — scratch, e.g. ~/tmp/1 or ~/tmp/foobar;
~/gtd/projects — various stuff, sorted by purpose, tag or/and date. Links from here to many other places;
~/gtd/income — various stuff, to be sorted;
~/examples — various working snippets;
/usr/share/bash-modules/ - various typical functions for bash scripts, e.g. "backtrace" or "..." (recently created as alternative to ~/examples/bash-..., see http://vlisivka.pp.ua/en/bash_modules ).
I use very simple tagging tool to speedup sorting, e.g. "s foo.tar.gz foo bar" will create two hard links to "foo.tar.gz" file in ~/gtd/projects/foo/ and in ~/gtd/projects/bar/ directories, and so on.
Currently, I use RPM packages only for my own projects, because they are easy to install/uninstall/upgrade, they contains documentation, changelog, and description, they are easy to verify or rebuild, and so on.
Sounds like it'd be really useful...
The beauty of a hosted SCM (I use Bit Bucket) is that I only have to remember to "pull" when starting work on a project and "push" when finishing and it is all kept safe :)
I swap between about 4 or 5 machines here and at work so the chances of keeping it sane otherwise are low :)
I already keep my projects (public and private) in version control (on GitHub).
~/Dropbox/code/<language>/<project name>/
it's all backedup and available immediately on all my machines, pretty handy. sometimes I use git inside of dropbox, but I'm still learning git in a real way so not all of my code is in it.
This is a fun thread to read, I'm starting to question my methods. At the very least seems like there is no reason not to have everything I write inside of git (or some version control).
- http://kitenet.net/~joey/cvshome/ (CVS)
- http://onlamp.com/pub/a/onlamp/2005/01/06/svn_homedir.html (SVN)
I keep small test/experimental bits of code in sub-directories of top level directories labeled Java_stuff, Lisp_stuff, Scheme_stuff, Ruby_stuff, Python_stuff, etc. Each test/experiment is in a well named sub-directory. These small experiments are useful for both learning and for later reuse on real projects.
I keep each active customer project in a directory with sub-directories for documentation, code, and test data.
For work on books: similar to customer projects: sub-directories for source code, for figure files (OmniGraffle and exported vector PDF files), for code examples, and for Latex (or OpenOffice if I can't use Latex).
I also keep a temp directory for downloading, building, running, and perusing source code for projects that I read about on the web. I periodically delete stuff in temp that is older than a few weeks old.
Finally, not specifically for code: I use Google documents to make copious deployment notes which I use for reference for future projects.
For extra backup (in addition to git remote repositories): I have a script that mounts a EBS volume on my always running EC2 instance, does an rsync to the EBS volume of almost everything but decrypted sensitive files, and then unmounts the EBS volume. EBS volumes are reasonably reliable.
~/p/slime ~/p/go ~/p/ccl ~/p/sbcl
In ~/p itself I'm putting some .el scripts, .txt, .bat, .sh, .cmd files for various updates (when going to the folder and doing "hg pull", "svn update", "git pull", etc. is not enough).
I think some sort of tagging filesystem would be appropriate.
Also, I hate how most programming tools assume I want to choose a "canonical" representation of code into files. I'd want to mostly don't care how the code is organized on disk and then write queries which let me view and edit code coming from multiple different files at once.
As a completely hypothetical, contrived example, let's say I was still doing Java and had a big class with many getters and setters, I don't want to choose whether I want the getter and setter of each attribute organised in pairs or whether I want all the getters first and then the setters. I want to be able to write a query that will constitute a new view, so if I want either option I just have to switch views. A third view would simply be the physical representation on disk, which is still needed from and dependencies-loading standpoint. This way of working would truly shine in much more complex scenarios but I hope you see what I mean.