1
Following some good practices that Visual Studio itself recommends, we cannot debug values of an object one by one using the "Object Initializer" or "Object Initializer". How best to get around this situation?
Ex.:
var myObject = new Object
{
Id = 1,
Nome = "Teste"
}
In the format above, when we put the breakpoint on the line of the id for example, they consider the code snippet as a whole.
3
There is no way. Only seeing the values after they were inserted into the object (see image below) or Initiating in the usual way, that would be:
var myObject = new Object();
myObject.Id = 1;
myObject.Nome = "Teste";
So it is possible to track line after line.
If you have filled properties with method returns, you can always enter the method using the key F11 and debug the method itself. Otherwise, it will hardly be necessary to track the fill line by line.
But when we have an initialization with many properties becomes unviable because I won’t know where the exception is taking place! Can you understand me?
You didn’t mention the exception in the question, @miltoncamara. If you are starting properties with return method values, you can enter the method using F11
The way you posted the image above, you can enter the initialization of the object by analyzing property by property as you assign the values?
Only if using some method in the assignment. Ex.: UserId = GetUserId(). Then you can enter the method GetUserId during the debug
3
Object initialization is a facilitator, if you want to debug this code you have to use the traditional style. It is true that Visual Studio could create a form for this, but today it does not have, so if there is no plugin to treat this differently, there is no way. Do:
var myObject = new Objeto();
myObject.Id = 1;
myObject.Nome = "Teste";
I put in the Github for future reference.
This way each boot will occur in a specific line and you can put breakpoint and walk step by step.
I changed the guy’s name because Object already exists on . NET and does not have such members.
This can be configured:
Exactly @bigown I already use this way you posted, but as Visual Studio suggests me the Object Initializer, I end up following the hint! But I lose debugging line by line!
In conclusion, the only way is this which you stated, correct?
Unless you have a plugin that I don’t know, I’ve searched for some time, there’s no other way.
1
There is a concept within OO who says that the ideal is for her class to change itself and not externally. I suggest that in order to debug the code and respect this rule, use the constructor to initialize the values.
public class Object
{
public Object(int id, string nome)
{
Id = id;
Nome = nome;
}
public int Id { get; private set; }
public string Nome { get; private set; }
}
var myObject = new Object(1, "teste");
Even for DTO’s?
And if you need to change a property do what?
then you create a public method such as Setname(string name); this way your class will continue to respect the rule and change itself and you will continue to debug.
@Ayrtongiffoni The compiler himself creates public methods to modify the properties. To do what you say is redundancy and prolixity.
redundant? note that I did not say that it is wrong, I only informed a concept of Object Orientation and through it, I suggested a way of doing. In this way, an outside class will NEVER modify the properties of this class.
That, redundant. I also didn’t say it’s wrong. Using a property (note that I said property and not field), an external class as well never will change a class member. The difference is that this is simplified.
Browser other questions tagged c# visual-studio encoding-style debug
You are not signed in. Login or sign up in order to post.
What do you mean? Can’t do what?
– Jéf Bueno
When we place the breakpoint, it considers the entire code snippet when we declare with Initialize Object. I will improve the question!
– mcamara