Неправильно ли изменять ключевое слово value в установщике?

#c#

#c#

Вопрос:

У меня есть установщик, которому необходимо обработать новое значение со старым значением. Однако, если значение < 0.1, ему необходимо присвоить значение 0.1.

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

Аналогично, если бы я посмотрел на код, я бы ожидал, что ‘value’ будет тем, что было передано установщику, а не чем-то манипулируемым.

Какой был бы лучший способ написать это, использовать newValue или ключевое слово value?

 public double NumberValue
{
    get => _numberValue;
    set
    {
        if (value < 0.1) value = 0.1;

        var multiplier = value / _numberValue;
        foreach (var item in Items)
        {
            item.SomeValue = item.SomeValue * multiplier;
        }
        _numberValue = value;
    }
}
  

Мой метод закончился так, что это гораздо более аккуратное решение

 public double NumberValue
{
    get { return _numberValue; }
    set
    {                
        var newValue = Math.Max(0.1, value);
        ProcessValues(newValue);
        _numberValue = newValue;        
    }
}
  

Комментарии:

1. Если свойство использует тип значения (int, byte, double, простой тип данных), а не ссылочный тип (строка, любой класс или коллекция), вы можете делать с этим значением все, что хотите. но я бы использовал подход @lewis, который он опубликовал в качестве ответа в этом случае, он короткий и все еще очень хорошо читаемый

2. «это кажется немного расточительным» — вы используете странную версию компилятора, где вам приходится платить за каждое объявление переменной? Любой метод (установщик свойств или нет), который вносит изменения в свои аргументы, обычно «разрешен», но может значительно усложнить понимание, если вы пытаетесь их отладить .

3. @Damien_The_Unbeliever Ха, скорее, если бы я использовал другую переменную, это было бы не так очевидно и читаемо, как ключевое слово value

Ответ №1:

Вот что я бы сделал:

 public double NumberValue
{
    get => _numberValue;
    set
    {
        _numberValue = value < 0.1 ? 0.1 : value;
    }
}
  

Другим способом, предложенным @Matthew в комментариях, было бы использовать Math.Max :

 public double NumberValue
{
    get => _numberValue;
    set
    {
        _numberValue = Math.Max(0.1, value);
    }
}
  

Комментарии:

1. К сожалению, мне нужно выполнить небольшую обработку с помощью поля backing, прежде чем я смогу его установить.

2. Можно также использовать Math.Max(0.1,value) вместо тернарного оператора. Функционально то же самое, просто зависит от предпочтений.

3. Молодец, @Matthew! Я добавлю это к своему ответу.

4. @MattNorrie Можете ли вы отредактировать свой вопрос, чтобы включить все ваши требования? Я был бы рад обновить свой ответ, если бы вы могли уточнить, какую другую обработку вам нужно выполнить. Вы всегда можете извлечь эту обработку в метод.

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

Ответ №2:

Технически это действительно не имеет значения. Какие различия существуют, так это в удобочитаемости.

Здесь я, вероятно, сделал бы _numberValue = value < 0.1 ? 0.1 : value; сам, потому что вся логика ясна, и это довольно идиоматичное утверждение охватывает все.

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

В пользу перезаписи также говорит то, что это вопрос ограничения value в пределах диапазона. Некоторые более разрозненные возможные варианты перезаписи не будут такими удобочитаемыми.

Как и во всех вопросах удобочитаемости, идеального ответа не существует, и всегда существует противоречие между преимуществом краткости в удобочитаемости и преимуществом краткости в удобочитаемости.