Comments on new project templates

I got a ton of comments on my post on the new project templates, and rather than try
to answer them in the comments, I thought I 'd answer them here, so they're at least
somewhat coherent to read.

Oh, and thanks for all the comments.

One more note: Some of the things that I did in the console app do not apply to all
apps. For example, if you're writing a class library, you're going to get /// comments
in front of your class and constructor, because I'm going to assume that you want
somebody to actually use the library at some point.

Dude, the tabs are best set at 4

The templates are all defined with hard tabs, but when they're converted to real code,
they'll get massaged into what you want (if you have the option set in Tools->Options).

You should leave the command-line arguments in there

I think we can agree that experienced programmers will know what to do here, so it's
mostly an for inexperienced programmers. An important argument for not having them
is that if they are there, when you are teaching programming, if they are there, you
have to explain what they are. Since you haven't talked about what a string variable
or an array is, you would prefer to put off those sort of discussions until later.
That's pretty much verbatim a request I got from a professor who teaches C#.

I'm a big fan of the building-block approach - which you already know if you've read
my book or columns.
Having to talk about things before you want to is a problem.

This is not an easy decision to make, but in this case, I think simplicity is
the more important concern. I will, however, take your comments under advisement.

The namespace should stay

Namespaces are mostly about organizing your code into useful components. But in a
console app, that really doesn't apply, since it is very unlikely to be used by other
applications. The namespace just adds complexity that you don't need.

One other comment was along the lines of "I didn't know you could do that". Namespaces
are just a convenient way to give classes and other types long, hierarchical names.

The comments / TODOs should stay

I think there are some comments that can be useful - for example, the SQL templates
will have comments that explain what you need to do to implement an aggregate function
in C#. Useful guidance there is great.

But comments are not always useful, and the ones we had in the console app fall into
the "not useful" bucket. They don't help novices because novices don't know what "entry
points are". I guess you can argue that the TODO is helpful because it guides the
novice on where to start, but the difficulty in finding the right place to put your
code is minimal in comparison to the difficulty in figuring out how to actually write
code that works.

If you consistently have trouble finding Main(), I respectfully submit that C# programming
may not be for you.

Credit to the team for removing the cruft but, hey, they put it in there too.

Absolutely. Our bad.

Editing and Customizing Templates

The way in which project templates are stored is more than a little ugly, and it's
not terribly obvious what file you should edit. This is deliberate. In previous versions,
there were concerns about improper modifications to the project templates causing
problems, so we made it cryptic to make this a less likely occurence.

Any takers on that? Anyone?

No, the truth is that we didn't spend a lot of time thinking about how users might
edit or extend the templates, and therefore, not surprisingly, it's not very approachable.

In the long term, we're planning on fixing that. "Long term" is code for "don't be
surprised if it doesn't show up in the next version".

In the short term, I'm hoping on writing - or getting somebody else to write - something
that explains how the templates work, how you can modify existing templates, and how
to create new ones.

How much time do templates save?

In the case of the console template, it's true that you can write that much content
fairly quickly. But the template also gets you a live project that has the source
file in it. Compared to creating an empty project and adding a new class and then
adding a Main() to that class (or adding an empty file and typing the text), and then
setting the project properties to get what you want, there is some benefit there.

One point to the XML doc comments: These are not only used to give guidance to someone using your library (as you seem to assume) but you might also use them for your internal documentation of your system. And in that case you do of course need them on every single class in your project. But then: Still the right decision to put them out by default, since if a team uses that approach, they can put them back in by hand. Two thumbs up for the changes!

FWIW, my book, has a whole chapter on how to customize the existing templates, and add new ones. So until there’s an official Microsoft document on how to do this, I’d obviously be more than happy for you to refer people to the book. 🙂 (Mastering Visual Studio .NET, from O’Reilly.)

I’m really pleased that you’re simplifying the templates. I was laughing the other day at a the XML conference in Boston how the first thing that every presenter did was delete the ///’s and //TODO’s, which is exactly what I do. In any case, I’d really like to see you make this customizable, based on an external template file. Then if people don’t like simple they can complicate it again.