Click here to Skip to main content
15,920,602 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi
I have a question about removing repetetive Commands, such as Console.WriteLine or StringBuilder.Append when writing many things.

We all know that we shouldn't repeat ourself (DRY) and maybe there's a more effient - less cluttering way to archieve the same Consoel Output, File Output or other things, and mabye even improve such things like Maintainability.
I dont want to spam, so I put a secreenshot here instead of a code example
(I know that it's horrible written, but it shows us the Problem I have)

This takes away space on my screen, and so it makes the code more confusing. I can't really think of a way of excluding it, perhaps in an resourcefile and then replace tags like [InsertDateHere] later with DateTime.UtcNow using String.Replace()

Please tell me if there's a common accepted way of doing so, because I think that this is bad programming and I want to impreove it.

Thanks for all your help guys, have a nice day.

Sincerely:
~Jonas
Posted

Hard to give some advice here, depends on the context and the need for abstraction.
First idea after looking 5 seconds to your code:
Create a format-string that represents your Report/document (whatever you call it), feed in all parameters. But if this code will be any better (maintainable), I don't know...

Also I don't see why this should be bad programming, you just don't have an abstraction for your Report/document. In my opinition DRY priniciple is only violated if you use the same code again, not if you call the same Routine 1000 lines in succession with different parameters....
 
Share this answer
 
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:
C#
public partial class Form1 : Form
{
    private static bool IsDebug = true;

    // in some method
    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.
 
Share this answer
 
v2
Comments
[no name] 16-Feb-15 11:57am    
> I might ask you why you had not adopted another debugging/testing strategy

that happened to me. They never understood it even tho I had order to make a console application.

--

Why is Console.Out better? It looks like nearly the same.

Oh... now i see how Preprocessor Directives work. I did knew that i had to define them, but i didn't know that visual studio knows that. I always thought i have to write code that somewhere detects weather it is in debug or not.

Thanks.
BillWoodruff 16-Feb-15 13:05pm    
Hi, Somehow a brief code example I put in my answer to you disappeared; I'll put it back in shortly.

If you are writing a Console Application, then Console.WriteLine is about all you've got to work with to write trace/debug information; of course, you can open a File and save information to the file (logging scenario).

"Why is Console.Out better? It looks like nearly the same."

Console.Out(SomeKindOfWriterParameter) ... I should have said ... is useful for re-directing Console activity, to change its default behavior (write to the Screen in a Console App, write to the 'Output Window in a WinForms App).

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900