First, your code example doesn't seem like "bad code" to me. Even if your code sample had one-hundred 'Console.WriteLine statements, it would not seem bad to me.
edit #1: And, all those calls to StringBuilder.Append don't look "evil," to me, either: I'd much rather see code I can follow along visually with what it's doing, than see one giant statement that's unreadable. You can always use some simple search-and-replaces to consolidate statements like that when you are confident the code is production ready. And, when code is production ready you might make other choices about where the string content goes (in a Resource, encrypted, compressed, etc.). In any case using StringBuilder is almost always a very good thing !
My evaluation would depend on the context in which I viewed your code: if your code was
in development, and I saw one-hundred 'Console.WriteLines, I might ask you why you had not adopted another debugging/testing strategy like formal unit-tests using some unit-testing framework. And, your valid reply might be something like: "you're looking at a prototype; we'll move to formal unit-testing when we reach proof-of-concept."
edit #2: If this is a Console App, Console.WriteLine is just fine: why dress-up a chicen in a tuxedo ?
There are other ways you can go about decorating your program so that certain code is only executed when certain conditions are met. One of these ways is "Preprocessor Directives" which can be quite complex, or very simple: [
^]. There's a CodeProject tutorial on these here: [
^].
edit #3L Restoration of "disappeard" code example: it's easy to roll your own alternative to using Preprocessor Directives; for example:
public partial class Form1 : Form
{
private static bool IsDebug = true;
private protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
{
if(IsDebug) Console.WriteLine("KeyData is: {0}", keyData);
}
}
edit #4:Finally, you can use the 'Console.Out method, passing it a reference to an instance a Class that inherits form one of .NET's "Writer" objects, to essentially override the standard behavior of Console.WriteLine; that's an advanced topic, and I am preparing an article for CP on using that in a WinForms Application that contains (I believe
at this time) some original ideas. I'll have to test that in a Console App, although I am pretty sure it will work.