Байт против логического значения для OrderBy - PullRequest
Новая
       18

Байт против логического значения для OrderBy

0 голосов
/ 07 мая 2019

Есть ли какой-то выигрыш в производительности при использовании байта по сравнению с bool при заказе?

Например, учитывая некоторый код: 

var foo = items.OrderByDescending(item => item.SomeProperty);

Существующий код для получения значения SomeProperty: 

public byte SomeProperty
{
    get
    {
        if (a == b)
            return 1;
        else
            return 0;
    }
}

Я хотел бы изменить этот код на: 

public bool SomeProperty
{
    get 
    {
        a == b
    }
}

Мне сказали, что первое более эффективно.Это правда?Есть ли недостатки использования bool поверх байта?

1 Ответ

1 голос
/ 08 мая 2019

Эффективность вряд ли будет в эффективности обработки.Это будет больше в эффективности кода разработки: код прост для понимания?легко использовать повторно для похожих предметов?легко изменить, если внутренняя структура меняется без изменения интерфейса?легко тестировать?

При проектировании недвижимости первым вопросом должен быть: что означает моя собственность?Что это значит?Есть ли у него идентификатор и тип, которые ожидают пользователи, или им придется искать его в документации, потому что они понятия не имеют, что это значит?

Например, если у вас есть класс, представляющий что-то устойчивоекак файл, и вы придумаете свойство, которое будет легче понять: 

class Persistable
{
    public int IsPersisted {get;}
    public bool IsPersisted {get;}
    ...

Кто из читателей сразу узнает, что это значит?

Итак, пока ваша идея оpersisted может иметь два значения, означающих «еще не сохранено» и «сохранено».Булева будет достаточно.Но если вы предвидите, что в ближайшем будущем представление о постоянстве изменится, например, постоянное может быть «еще не сохранено», «сохранено», «изменено после того, как оно сохранено», «удалено».Если вы предвидите это, вы должны решить, лучше ли вернуть бул.Возможно, вам следует вернуть перечисление: 

public PersistencyState State {get;}

Заключение Разработайте идентификаторы и типы ваших свойств и методов таким образом, чтобы кривая обучения для ваших пользователей была низкой, а ожидаемых изменений не было.не оказывает большого влияния.Убедитесь, что свойства легко тестируются и поддерживаются.В редких случаях переносимость является проблемой.

Эти элементы оказывают большее влияние на вашу эффективность, чем два изменения кода.

Вернуться к вашему вопросу

Если вы думаете о том, что представляет SomeProperty, и думаете, что оно представляет равенство a и b, то вам следует использовать:

public bool EqualAB => a == b

ЕслиВаш вопрос о том, следует ли использовать «get» или =>, первый вызовет что-то вроде подпрограммы, в то время как второй метод вставит код.Если часть после => достаточно велика, и вы используете ее в сотнях мест, тогда ваш код станет больше.

Но опять же: если ваш get действительно большой, вы должны сделать его свойством? 

public string ElderName
{
    get
    {
        myDataBase.Open()
        var allCustomers = myDataBase.FetchAllCustomers().ToList();
        var eldestCustomer = this.FindEldestCustomer(allCustomers);
        return eldestCustomer.Name;
    }
}

Что ж, это окажет существенное влияние на размер кода, если вы используете нотацию => на 1000 местоположений.Но, честно говоря, разработчики, которые помещают это в свойство вместо метода, не заслуживают эффективного кода.

Наконец, я спросил здесь в stackoverflow, есть ли разница: 

string Name {get => this.name;}
string Name => this.name;

ответ был, что он переведен на тот же код ассемблера

...