This post originated from an RSS feed registered with .NET Buzz
by Frans Bouma.
Original Post: Get rid of the 'file' concept for sourcecode!
Feed Title: Frans Bouma's blog
Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/fbouma/Rss.aspx
Feed Description: Generator.CreateCoolTool();
After the recent sourcecode control debate I started thinking: why on earth are we still using the 'file' as the base unit to store sourcecode in? The whole 'file' concept is pretty bad and limiting when it comes to sourcecode control, code reuse and overall code management. Much better would it be if we could work with a code repository as the container for our sourcecode which would work with sourcecode elements like we know, e.g.: namespaces, classes, assemblies, resource objects etc. etc.
In your IDE, for example Visual Studio.NET, you then would work with solely a view on the sourcecode in the repository, thus a subset (or all) of the elements in that repository. The list of advantages of this approach is practically endless. First of all, because the repository contains elements, not files, you can include elements like classes or enums into your code without having to browse through files and wondering where a particular class is located. Second, you can enable sourcecode control on the element level rather than the file level. Also, sourcecode control can be build into the same medium you use to store the actual code in the first place: the repository itself. Of course you can think of many other advantages.
Why we're still using files for sourcecode, especially sourcecode written in OO languages, is beyond me: the concept of using an IDE for software development is very common, so offering a new way of looking at where sourcecode is stored should be considered in the IDE of at least tomorrow, but frankly, it should already be build into the IDE of today.
And the file focussed developer who's not using an IDE? He still can store his code in files, an IDE working with a repository can also use a file driver which reads all files in a project, and works with those files as one single repository. Let's hope at least in the Longhorn release of Visual Studio.NET, Microsoft considers this approach as an alternative to the 'file' concept. After all, the file system of longhorn is a database , so using that functionality for a repository would be the logical thing to do.
Previous Topic
