Recently I had the pleasure of helping out a former employer of mine resolve a couple minor issues that have come up since my departure. During this time I had a revelation about how we treat our source code today, and how we should treat it tomorrow.
When I worked for this company I became the sole developer, and was able to define my own coding standards. Overtime all of the source files were updated, as I made changes to them, and was able to use Reformat Document tool in Visual Studio.
Since I have left, a new developer has taken ownership of all the projects I was working on. Said developer prefers a different style to their code. For example. I prefer all braces to start on a new line where as he prefers all opening braces to exist on the parent line.
What does this have to do with how we treat source code? Well imagine this scenario. I open up a large class file, and remove a single using statement from the top of the file. Upon saving the file, visual studio applies my formatting rules which I defined. This results in my one line change to cascade into hundreds of changes.
The question I pose then is why do our tools treat non-significant characters such as extra white space as significant when comparing two versions of the code? Shouldn't our development tools store the source code in as compact a format as possible and allow us to define our own personal views of the source code? Two developers on the same team should be able to read the same source code formatted how they like to see it.
Perhaps Visual Studio should be written as a MVC, and allow us to define our own views seperate from the source code.
Writting this reminded me of when I worked on VB6 applications and one developer would check out a file and the casing of all the variables would change. What a nightmare. Again the source code should be treated as data rendered into a view by the IDE.
1 comment:
Post a Comment