As you write, debug? What established techniques exist?

(I put the average complexity, because interested in the opinion of experienced colleagues)

How do you optimally write to include\disable debug in case if fixies ruin it all?

The most simple idea:
public class Container {

private List<cell> Cells = new List<cell>();

public bool AddCell(Item item)
{
 Cells.Add (new Cell(item));

 Debug("Add new Cell in {0}, with item id {1}", Cells.Count - 1, item);

 return true;
}

public bool IsDebugEnabled = false;
private void Debug(string str)
{
if(IsDebugEnabled)
Debug.Print(str);
}
}</cell></cell>


And whether in your opinion the meaning of all this debug to write, if all the functions 2-10 lines?
Maybe you know some better solution for writing debug?
June 3rd 19 at 18:54
3 answers
June 3rd 19 at 18:56
Usually in the services/classes where you want logging/debug prokidyvaya logger and use levels of logging to output or not output different information.
Then, if necessary, debug when you run the application as a parameter to specify the level of logging and get the logs. And by default, for example, use type level QUIET/NONE/OFF (in different loggers for different).

And for the debug use the debugger.
Debugger is a debugger?
I know (about the debugger), but I want to close the code in the dll and there triggering event debug that if there are subscribers, then the debug will fly farther, although I'm not sure that a whole lot of sense, because the same language write, in which case it is not difficult to transfer 30 files instead of one folder in another project.

Levels of logging just for the color effect, as I understand it. It is not essential for me. - Cristian92 commented on June 3rd 19 at 18:59
The levels of logging affect gets the message to the destination Loka (file system, console, SQL Server, etc.) or not. - General_Miller commented on June 3rd 19 at 19:02
, "debug event" is breakpoint, and you write about something else. - Keira commented on June 3rd 19 at 19:05
Not, well, reading logs sent by the user is also debug in General.
But the above just in case the author said. And you know that a lot of novice developers like debajit prints to the console, resulting in crutches and dancing with a tambourine. - Justice.Nienow commented on June 3rd 19 at 19:08
June 3rd 19 at 18:58
own implementation of logger in each class quickly tire..
1 - there are https://msdn.microsoft.com/ru-ru/library/system.di... there are many ready-made tools
2 - you can implement your own simple logger in the form of expansion (in a static utilitarian class) example
internal static void log(this string txt) => tbLog.AppendText(txt + Environment.NewLine);

then it is very convenient to use anywhere
$"something went wrong, the first parameters {x} and the second {y}".log();

3 - another convenient option of the compiler for structures, which is clearly not needed in production
#if DEBUG
 var sw = new Stopwatch();
sw.Start();
#endif
 /// what we do
#if DEBUG
sw.Stop();
 var ts = sw.Elapsed;
 $"total time '{name_of_action}':".log();
$"\t{ts.Hours:00}:{ts.Minutes:00}:{ts.Seconds:00}.{ts.Milliseconds:000}".log();
#endif
June 3rd 19 at 19:00
To debug the application, usually uses an integrated approach and it is dictated by the situation.
First, to debug the behavior you can use what is called the debugger to put breakpoints and go step by step with a test to see how changing the tracked data.

Secondly, to debug the application, use the logging levels.
Logging level TRACE: you write whatever you think is right, all you will help then to understand how the process worked. In practice, this is a huge number of messages, the usefulness of which in normal circumstances is extremely low.
The logging level is set to INFO: you are writing informational messages, for example, about the change of status process.
And so on through the levels.
Your logging system cuts off everything that below an acceptable level, not fixing it.

In addition to the above, for debugging, or rather, in order to be sure that everything goes exactly how it should go, write the tests. Unit tests, integration tests, UI tests, etc. And all this, in total (logging and performance tests), gives a relatively complete understanding that everything is going as it should, but if not - you can see that in test A all broke, and the logs that broke it.

Find more questions by tags DebuggingC#