Это плохой стиль кодирования, чтобы не назначать новый экземпляр переменной?

Question

В верхней части моей программы есть сегмент кода, который выглядит следующим образом

var XXXAssembler = new XXXAssembler(ctx);
XXXAssembler.LoadXXX();

var YYYAssembler = new YYYAssembler(ctx );
YYYAssembler.LoadYYY();

var ZZZAssembler = new ZZZAssembler(ctx);
ZZZAssembler.LoadZZZ();

В приведенной выше логике я использую каждый varaible один раз для вызова соответствующего загрузчика и не использую переменные где-либо еще.

Я могу изменить код на этот

new XXXAssembler(ctx).LoadXXX();
new YYYAssembler(ctx ).LoadYYY();
new ZZZAssembler(ctx).LoadZZZ();

Это уменьшает размер кода, но я хотел бы думать, что это также упрощает его. Я мог видеть полезность переменных для отладки, но я не думаю, что это обязательно хорошая причина. Другие могут не согласиться.

Считается ли не поддерживаемая версия плохим стилем кодирования?

Answer 1

Если вы не собираетесь использовать объект, назначенный переменной Assembler, тогда в этом нет необходимости.

Я бы сказал, избавиться от него, очистить код, а затем, если вам нужнопозже ты сможешь вернуть его обратно.

Answer 2

Если вы спросите меня, размер кода не имеет значения.Важно только то, что, когда вы видите код через год, вы знаете, как он выполняет то, что ему нужно, и как переписать / повторно использовать / и т. Д.

Answer 3

new XXXAssembler(ctx).LoadXXX(); абсолютно нормально, если вы не используете ссылку, возвращенную new XXXAssembler(ctx) в другом месте.

Answer 4

Как вы упомянули, единственная техническая причина присвоения созданного объекта переменной - это необходимость его использования или его просмотр где-либо. Если вы уверены, что вам это никогда не понадобится, вам не нужно создавать новую переменную, и вы можете немного сократить свой код.

Но я предложу две оговорки:

(1) Я часто нахожу, что мне нужно посмотреть на вывод метода, прежде чем он вернется, или на экземпляр объекта, созданного новым оператором, когда я отлаживаю. Поэтому иногда вместо этого:

public MyObject ReturnSomeObject()
{
    return new MyObject();
}

Я сделаю это вместо:

public MyObject ReturnSomeObject()
{
    var myObject = new MyObject();
    return myObject;
}

Просто чтобы я мог посмотреть на это в отладчике. Это немного загромождает мой код, но может быть очень полезно, когда я пытаюсь выяснить, почему что-то пошло не так.

(2) Если вы обнаружите, что вы можете делать то, что вы описываете очень часто, вы можете более внимательно взглянуть на структуру ваших классов. Какой смысл в классе, у которого есть метод, который ничего не возвращает и который не изменяет внутреннее состояние класса любым способом, который вас интересует? Чтобы взять приведенный выше пример, предположительно, ваши различные методы LoadXXX () должны возвращать некоторый код состояния, или изменять какое-либо свойство status объекта, или возвращать указатель на загруженный файл, или, ну, что-то . Если они это сделают, но вы не потрудитесь посмотреть на это - ну, это еще одна проблема Если методам на самом деле не нужно изменять какой-либо аспект внутреннего состояния объекта, то вам следует обратить пристальное внимание на то, чтобы сделать их статичными: это позволяет вам избегать запуска конструктора класса при каждом их вызове, оно более четко выражает их намерения, и это позволяет компилятору уведомить вас о возможной несогласованности, если вы do решите, что им необходимо изменить состояние объекта в какой-то момент в будущем.

Здесь нет ничего сложного, только некоторые рекомендации.

Answer 5

Я думаю, что не присвоение переменной - это хорошо. Я делаю это во многих случаях, например для некоторых юнит-тестов new Mock<IInterfaceToMock>.Object или для функторов обратных вызовов SomeFunctionAcceptingCallback(args, new CallbackHandler()).

Answer 6

Если вы больше никогда не собираетесь использовать Объект, но для этого случая я не вижу смысла давать им имена. Он добавляет ненужные строки в ваш код.