We’ve begun work on this and are considering changing the default location for new projects to C:\\USERPROFILE\Source\repos. Would this be a reasonable change to address the problem of “clutter” in the Documents folder? This is currently the default for cloned repositories, so all projects would be in a singular default location.
As well, you still retain the option to change the default if you’d like.
Program Manager – VS IDEMan na commented
The problem isn't particular to this issue. It's a systemic problem created by Microsoft software design philosophy which is fundamentally broken and exhibited on all their products. Interestingly, some of Microsoft's most usable software was written on the Mac.
On one hand, it offers so many dizzying configuration options that it becomes overwhelming. The options dialog, the context menus and the main menus in VS, for instance, have so many options that you often wish there was a find facility. Of course, what you're usually looking for is deeply nested in some hierarchy and you're often presented ambiguity as to whether the option is correct.
On the other hand, Microsoft tries to use "intelligence" to do what it thinks is best for you. Often what it does for you is exactly what you don't want it to do. We want to organize information in a way that makes sense for us wether we're doctors, lawyers, gamers or software developers. Microsoft pulls a BOB and assumes we want to store all our documents in the My Documents folder.
Even worse, Microsoft tries to prevent us from hurting ourselves by hiding things from us. I remember explaining to a crying PHD student that all their mail correspondence was lost even though they were vigilant in backing up their drive. Apparently, the backup software they were using didn't backup files marked as hidden and their Mailbox files were deeply nested in their profile inside a hidden directory.
34 votesMan na commented
I believe the Visual Studio Team Foundation Server used XAML as a build definition language as of TFS 2013 in favor of a "simpler task- and script-driven cross-platform build system." Now that .NET is cross platform, it shouldn't be much of a barrier anymore, which makes me wonder if "simplicity" and "script-driven" are the real motivation behind abandoning it. Given the fact that build systems are procedural by nature, I would hazard to guess procedural definition is probably a better fit.
Perhaps moreso, I think XAML was foudn to be too crufty and verbose to effectively work with. To set the record, I am not one of those young developers who eschew typed languages in favor of dynamically typed ones for no reason other than to save a few keystrokes. If I had to pick a declarative markup language, JSON appears to be far better choice. In fact, old age wisdom of the 1980's chose the .res or resw formats to describe application resources well before XML, since it's syntax is quite similar to JSON.
Defining and editing a few objects in XML can easily turn into pages of confusing and hard to follow labyrynth of text despite intellisense, color coded tags and automatic indentation facilities. It inherently suffers from the same thing that makes HTML difficult to edit and follow. Consquently, a graphical editors usually become insufficient or limiting, requiring frequent round trips between the graphical and text editors. Even after several decades of HTML, most of its development is still done using the primitive text editor. In contrast, PostScript, an older and almost as widely used language suffers from a shortage of programmers because the language can be so easily generated and rendered that it makes hand coding it tantamount to programming in assembly language with little to no benefit.