Это эффективный способ анализа параметров функции? - PullRequest
Новая
       7

Это эффективный способ анализа параметров функции?

0 голосов
/ 27 апреля 2018

Итак, я новичок в C #, но одна вещь, которая мне уже нравится, если исходить из других языков более высокого уровня, - это возможность выполнять побитовые операции в (близко к) C. У меня есть набор функций, где некоторые или все параметры являются необязательными, и мне нравятся переключатели, поэтому я создал функцию, которая преобразует логические массивы в беззнаковые шорты, что позволяет мне в основном смешивать логический массив в одно значение для переключателя: 

namespace firstAsp.Helpers{
    public class argMux{                       
        public static ushort ba2ushort (bool[] parms){  
            //initialize position and output                
            ushort result = 0;
            int i = parms.Length-1;
            foreach (bool b in parms){
                if (b)//put a one in byte at position of b
                    //bitwise or with position
                    result |= (ushort)(1<<i);
                i--;
            }
            return result;               
        }
    }
}

Вот пример использования: 

public IActionResult Cheese(string fname,string lname)
    {
        bool[] tf = {fname!=null,lname!=null};

        switch(argMux.ba2ushort(tf)){
         case 3:
            @ViewData["Data"]=$"Hello, {fname} {lname}";
            break;
         case 2:
            @ViewData["Data"]=$"Hello, {fname}";
            break;
         case 1:
            @ViewData["Data"]=$"Hello, Dr. {lname}";
            break;
         case 0:
            @ViewData["Data"]="Hello, Dr. CheeseBurger";
            break;
        }
        return View();
    }

Мой вопрос: это эффективный способ сделать это, или есть способ, который превосходит? Я стремлюсь к простоте использования, которая, безусловно, обеспечивает для меня, но я также хотел бы, чтобы это был эффективный код, быстрый во время выполнения. Есть указатели? Это глупый способ сделать это? Любая обратная связь приветствуется, вы можете даже назвать меня идиотом, если вы верите этому, я не слишком чувствительный. Спасибо!

1 Ответ

0 голосов
/ 27 апреля 2018

Это все плохо.

Правильный способ написать свой метод - не использовать ничего из этого: 

public IActionResult Cheese(string firstName, string lastName)
{
    @ViewData["Data"]=$"Hello, {firstName ?? "Dr."} {lastName ?? "Cheeseburger"}";
    return View();
}

Одна вещь, которая мне уже нравится из других языков более высокого уровня, - это возможность выполнять побитовые операции в (близко к) C.

Если вы пытаетесь решить бизнес-проблему высокого уровня, вы, вероятно, делаете что-то не так. Решите бизнес-проблемы высокого уровня с помощью бизнес-кода высокого уровня.

Кроме того, если вы используете неподписанные типы в C #, шансы хорошие, вы делаете что-то не так. Типы без знака предназначены для взаимодействия с неуправляемым кодом. Очень редко можно использовать ushort, uint или ulong для чего-либо еще в C #. Количества, которые являются логически неподписанными, например длина массива, всегда представлены в виде количеств со знаком.

В C # есть много функций, разработанных для обеспечения того, чтобы люди, имеющие библиотеки COM, могли продолжать использовать свои библиотеки, и чтобы люди, которым нужна необработанная, неконтролируемая производительность арифметики с указателями, могли делать это, когда это достаточно безопасно. Не путайте существование этих низкоуровневых функций программирования как доказательство того, что C # обычно используется как низкоуровневый язык программирования. Напишите свой код так, чтобы он четко читался как реализация бизнес-процесса .

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

Теперь, может быть в некоторых случаях, когда подобные вещи разумны, и в этих случаях вы должны использовать перечисление, а не рассматривать короткое как битовое поле : 

[Flags]
enum Permissions 
{
  None = 0x00,
  Read = 0x01,
  Write = 0x02,
  ReadWrite = 0x03,
  Delete = 0x04,
  ReadDelete = 0x05,
  WriteDelete = 0x06,
  ReadWriteDelete = 0x07
}
...
static Permissions GetPermission(bool read, bool write, bool delete) {
  var p1 = read ? Permissions.Read : Permissions.None;
  var p2 = write ? Permissions.Write : Permissions.None;
  var p3 = delete ? Permissions.Delete : Permissions.None;
  return p1 | p2 | p3;
}

А теперь у вас есть удобный 

switch(p)
{
  case Permissions.None: ...
  case Permissions.Read: ...
  case Permissions.Write: ...
  case Permissions.ReadWrite: ...

Но обратите внимание, что мы храним все в бизнес-сфере . Что мы делаем? Проверка прав доступа . Так как же выглядит код? Как будто это проверка прав доступа . Не переворачивать кучу битов, а затем включать целое число.

...