Ответ 1
Не использовать Dim
jack = 12
? jack
12 {Integer}
Это может спасти меня так много времени. Иногда я нахожу, что пишу такие вещи в часах или в ближайшем окне:
MyObject.Function1.Fuction2.Fuction3.Fuction2
Вместо этого я мог бы просто объявить несколько новых переменных и сделать это более структурированным образом.
Однако делать это не допускается.
Есть ли способ, которым я могу это сделать? Будет ли поддержка для того, что я хочу в любых будущих версиях?
Не использовать Dim
jack = 12
? jack
12 {Integer}
Просто отвечая на вопрос из заголовка:
В VS2015 вы можете объявить переменные в непосредственном окне. Но вы должны закончить свою команду с помощью точки с запятой:
var abc = "abcdef";
Expression has been evaluated and has no value
или
var n = 7;
Expression has been evaluated and has no value
или
int o = 8;
Expression has been evaluated and has no value
Чтобы показать результат, просто введите имя переменной:
abc
"abcdef"
или
?abc
"abcdef"
или
?abc;
"abcdef"
или
abc;
"abcdef"
С помощью С# вы можете объявлять переменные в непосредственном окне во время отладки (я честно не знаю, является ли это только функцией VS2008, но я только что проверил ее в редакции VS2008).
Вы не можете объявить переменную в окне просмотра (на самом деле сообщение об ошибке говорит, что "Операторы декларации разрешены только в непосредственном окне" ), но вы можете наблюдать за любыми переменными, которые вы создали в непосредственном окне.
Кроме того, вы не можете использовать var
при объявлении переменных в непосредственном окне, но помимо этого вы можете делать то, что вы просите.
@AMissico указала мою предыдущую ошибку - видимо, вы можете сделать это в VB.NET с неявным назначением.
Я все же считаю это костылем, и если бы мне когда-либо приходилось это делать, я бы начал спрашивать, почему программа структурирована таким образом, что это необходимо.
Если вам нужен этот уровень отладочной информации, лучше использовать его в своей программной логике - таким образом, когда будущие программисты обслуживания должны отлаживать один и тот же путь кода, они будут иметь все те же детализированные информации без необходимости "опроса" глубоко вложенных графиков объектов. Вместо записи MyObject.Function1().Function2().Function3()
напишите:
var first = MyObject.Function1();
var second = first.Function2();
var third = second.Function3();
Затем вы можете выполнить фактическую логику программы в отладчике вместо написания всего теста script в окне Immediate.
Вы также можете написать собственный Debugger Visualizer, если вам нужно получить подробное представление сложного объекта или иерархии.
Это может быть альтернативой. Вы можете использовать Test Test Bench для создания экземпляра MyObject и вызвать метод экземпляра с любыми аргументами, которые вам нужны (или просто вызвать метод без создания экземпляра, если это статический метод).
В дополнение к тому, что говорит Aaronaught, такие конструкции, которые вы описываете, нарушают Закон Деметры. Возможно, вам захочется рассмотреть возможность реструктуризации вашей программы, чтобы такие конструкции не нужны. На самом деле даже предлагаемое решение поддерживает нарушение надлежащего разделения проблем.
Если метод ссылается не более чем на один уровень косвенности, то поведение отладчика будет более подходящим для приложения.