One Class Per File

I've been using C# as one of my primary languages for the past 6 years where I currently work. Prior to that I was working with Java. One of the immediate differences that I noticed was that it was not uncommon to have multiple public classes in a source file. C# allows it, so why not.

Coming from a Java background I was used to one public class per file, where the filename needed to match the public classname in the file, and for me... I preferred it that way. I felt that it helped to organize the code. Some may say, having multiple classes in a file can aid in readability/discoverability/understandability/insert-an-ability. All true, they can. It can also be harmful in each of those respects as well... all depends. 

This week I've discovered a new reason why I prefer one class per file. Changes to classes are more traceable if a class has it's own file. Huhhh?

The reasoning goes like this. If I start out and have a couple of small public classes in a file, then tracking changes doesn't seem too difficult. The problem comes in when the classes grow. Your file will becomes larger and larger, and when you look at the file, there might all of a sudden be too many concepts in the file for you to keep track of. This can especially be the case where you can have a file named a name that has nothing to do with any of the classes inside of it (poor form imo, but to each his own). Some of the classes in the file may be related to the filename, but if sloppiness has crept in (not unheard of) then other classes may not be as closely related to that filename. Different concepts and abstractions may have crept into the file, and you may not realize it for a while. Yuck.

Then one day your in the file and your like, ZOMG, this file is too large and has too many concepts in it, I have to tease it apart. And so you do. You become the boy scout and you tease classes out of it, putting them in their respective files with the respective filenames and namespaces. And when you do this, your original file can in the worst case be empty (remember, the filename doesn't have to match any of the classes, and you just teased all of the classes out). And so you delete it. No problemo dude. And then you commit it and push it up to the remote (because your working in git).

And now, well now all of the history that you had in commit messages is gone for every class that was in the original file. It's not like renaming a file in git. You can always use the `--follow` flag on the current file you have to retrieve the full commit history for that file.

git log --follow path/to/filename 

Unless your a good tracker, chances are you're not going to re-discover where those commit messages went for the deleted file. Perhaps you'll never need to. I hope so.

Commit messages are a blessing for both me and my fellow developers because they are in some part a diary of what we were thinking about when we made changes. I've been getting more and more accustomed to making rather large commit messages lately. I'm recording more of the thoughts that I had around the design choices I've used, and perhaps even recording patterns I used in the commit.

The history of changes to a class is important to me. Maybe I've found some religion on this issue, and most probably, I'm going to be more prudent on keeping... one public class per file come Monday.

References:
Brad Abrams - Design Guidelines, Managed code and the .NET Framework
- Source files should contain only one public type, although multiple internal classes are allowed

Git: What happens when the remote goes away?

I have found myself working on several different after hours projects over the past few years. There are times when a project lies dormant for quite a while. And when you go back to pick up the pieces for a dormant project you might not remember where everything was/is. In my case, I forgot where the project was actually being hosted. Meaning, was it still on GitHub, or had it been moved over to Bitbucket? Or was it neither place. There had been a migration that had happened over to Bitbucket as they allowed the cost of housing the remote to stay, well... free.

I started looking at my local machine and finally found where I had tucked away the code. But when I tried to ask git where it was pointing to I got an error:

git remote show origin

ERROR: Repository not found.
fatal: The remote end hung up unexpectedly

Ooops, that didn't work out. My curiosity was peaked though. Surely there was a way to get at this information even though the remote might not be there any longer. And there is. You can ask your gitconfig for it:

git config --get remote.origin.url 

git@github.com:sware/duoness.git

This is telling git to get the url of the remote's origin repository out of the local configuration information.

What is duoness you may ask? It stands for "Do Unto Others-ness". It hopes to be a record of people either having done a random act of kindness or having received a random act of kindness. Time will tell if it makes it out to production.