Что коллеги-разработчики думают об условном операторе?

Question

Мне действительно очень нравится условный оператор в C#. Это делает мою жизнь намного проще в написании такой логики:

public  string FormattedFileName
    {
        get
        {
            return string.Format("{0}_{1}_{2}_{3}.xls", 
            DateTime.Now.Month.ToString().Length == 1 
             ? "0" + DateTime.Now.Month.ToString()
             : DateTime.Now.Month.ToString(), 
            DateTime.Now.Day.ToString().Length == 1 
             ? "0" + DateTime.Now.Day.ToString()
             : DateTime.Now.Day.ToString(), 
            DateTime.Now.Year.ToString(), 
            "DownLoaded_From_Clients");
        }
    }

Конечно, это означает, что я теряю читабельность кода. В любом случае, мне просто любопытно, что думают другие разработчики по поводу такого подхода к написанию кода. Благодарю. Я одинаково ценю как негативные, так и позитивные комментарии.

Answer 1

Нравится? Используйте это: не

// if (Like it) then (Use it) else (Don't)

Answer 2

Когда вам это нужно, троичный оператор неоценим. Тем не менее, я думаю, что часто есть лучшие способы выразить себя. В приведенном вами примере почему бы не использовать строку формата, которая будет делать именно то, что вы хотите: "{0:00}_{1:00}_{2}_{3}.xls", позволяющий значительно упростить ваш код?

Answer 3

У вас есть пример злоупотребления условным оператором,

Это можно выразить гораздо более четко следующим образом:

public string FormattedFileName
{
    get {
       return DateTime.Now.ToString("MM_dd_yyyy") +
          "_DownLoaded_From_Clients.xls";
    }
}

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

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

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

Например:

a == null? "empty" : a

можно заменить на:

a ?? "empty"

Answer 4

Если вы хотите сделать его более читабельным, вы всегда можете выделить вызовы в вызовы getCurrentMonth(), getCurrentYear, getCurrentDay....

Answer 5

Комиксов парень говорит. "Худшее использование троичного оператора когда-либо."

Answer 6

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

Answer 7

Мое личное эмпирическое правило таково: если совершенно очевидно, что делает троичный, тогда все в порядке. Если он втиснут в одну строку только для того, чтобы кодер мог использовать троицу, тогда это должен быть оператор if в скобках.

Answer 8

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

Answer 9

Мне действительно не нравится, как ты это использовал. Я использую его, когда легко помещаю его в одну строку вместо использования многострочного оператора if.

Answer 10

Я за использование условного оператора, но он тебе здесь не нужен...

return string.Format("{0}_{1}_{2}_{3}.xls", 
    DateTime.Now.Month.ToString("00"), 
    DateTime.Now.Day.ToString("00"), 
    DateTime.Now.Year, 
    "DownLoaded_From_Clients");

Answer 11

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

Answer 12

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

Answer 13

При взгляде на "функциональный" мир, где вы не можете "делать" вещи условно, условный оператор встречается очень часто. Так или иначе, у меня сложилось впечатление, что функциональная парадигма набирает интерес, потому что она убирает временный поток управления, вызванный заявлениями "если (это) делает другое". Это упрощает определение того, что вы имеете в виду, вместо того, чтобы указывать компьютеру, что делать.

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

Отладка - это другое: например, в C++ нельзя поставить точку останова только для одной из ветвей.

Answer 14

Почему бы не сделать что-то более подобное?

public  string FormattedFileName
{
    get
    {
        return string.Format(
            "{0}_{1}_{2}_{3}.xls", 
            DateTime.Now.Month.ToString().Length == 1 ?
                "0" + DateTime.Now.Month.ToString() :
                DateTime.Now.Month.ToString(), 
            DateTime.Now.Day.ToString().Length == 1 ?
                "0" + DateTime.Now.Day.ToString() :
                DateTime.Now.Day.ToString(), 
            DateTime.Now.Year.ToString(), 
            "DownLoaded_From_Clients");
    }
}

Заметьте, я вообще не менял код, только форматирование. Как уже отмечалось, вам не нужно использовать условный оператор здесь, но небольшая осторожность с отступом может значительно улучшить читаемость. Мне нравится условный оператор, но если вы запустите весь свой код в плотном блоке без отступов, он будет нечитаемым независимо от того, какие операторы вы используете.

Answer 15

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

Answer 16

Несколько скобок помогают читабельности.

Попробуйте добавить их, чтобы уточнить, что именно делает ваш оператор чередования, и у вас все будет хорошо.:)

Answer 17

Он называется троичным оператором (в конце концов, мы не называем двоичный код вторичным кодом), и его уже спрашивали:

Это разумное использование троичного оператора?