Если Вы не можете использовать базовое имя, как предложено в других сообщениях, можно всегда использовать sed. Вот (ужасный) пример. Это не является самым большим, но это работает путем извлечения требуемой строки и замены входа требуемой строкой.
echo '/foo/fizzbuzz.bar' | sed 's|.*\/\([^\.]*\)\(\..*\)$|\1|g'
, Который получит Вас вывод
fizzbuzz
Использование оператора?: Должно быть ограничено, чтобы сделать код более читабельным. Классический пример:
a = sprintf( "There are %i green bottle%s on the wall.", i, (i==1?"":"s") );
В этом случае код будет менее читабельным, если вы разбили его примерно на 5 строк if / else.
Я обычно заключаю в скобки весь оператор, чтобы при чтении я мысленно проанализировал его как единственное значение.
messageColor = (color != null ? color : messageColor);
Другой вариант -
messageColor = color || messageColor;
, который на некоторых языках будет оцениваться как «цвет, если только цвет не оценивается как« ложь », и в этом случае значение messageColor. На мой взгляд, этого следует избегать, так как это может сбить с толку людей .
Самое главное - быть последовательным, чтобы у следующего человека, читающего ваш код (даже если это вы), были минимальные когнитивные издержки.
Читаемость, легкость понимания и т. Д. В этом случае такие же ( Я имею в виду, давай ... ). Мне не нравится дублирование и кажущееся самоопределение в первом примере; это будет выглядеть примерно так:
if (colour != null) {messageColour = colour;}
else {messageColour = messageColour;};
что немного глупо.
Я обычно пишу вторую в одной строке, но это вопрос индивидуальной фантазии, соответственно. рекомендации по стилю кодирования:
if (colour != null) {messageColour = colour;};
РЕДАКТИРОВАТЬ (сейчас я более самоуверен, чем 8 лет назад)
Поскольку вы ищете передовой опыт:
// Use default visibility by default, especially in examples.
// Public needs a reason.
class MessageFormat {
static final Color DEFAULT_COLOR = Color.RED;
// Strongly prefer final fields.
private final Color messageColor;
// Protect parameters and variables against abuse by other Java developers
MessageFormat (final Person person) {
// Use Optionals; null is a code smell
final Optional<Color> preferredColor = person.getPreferredColor();
// Bask in the clarity of the message
this.messageColor = preferredColor.orElse(DEFAULT_COLOR);
}
}
Использование тернарного оператора часто является деликатным вопросом наряду с другими стандартами кодирования. Его использование, вероятно, лучше всего определяется стандартами кодирования на вашем сайте.
Однако в этой конкретной ситуации я определенно рекомендую второй вариант; это не только более понятно, но и в использовании тернарного оператора здесь нет необходимости. Нет необходимости повторно назначать messageColor самому себе, поэтому единственной функцией тернарного оператора в этой конкретной ситуации является обфускация кода.
Тернарный оператор более распространен среди программистов на C. В C, если вы избегаете управляющих структур, вы часто можете улучшить конвейерную обработку, поскольку нет предсказания ветвления, которое могло бы пойти не так. Я сомневаюсь, что вы заметите какую-либо разницу в производительности в Java, а шаблон if-null-then-assign гораздо более распространен, чем тройной. Однако, если вы поддерживаете существующую кодовую базу, обычно лучше придерживаться существующего кода.
Если вы обнаружите, что делаете это часто, вы можете написать defaultIfNull
, firstNonNull
или объединить функцию
, которая может сделать код еще более кратким. Apache Commons Lang включает функцию defaultIfNull
.
Некоторые языки включают оператор || =
, это обычная идиома для значений по умолчанию на этих языках.
Тернарными операторами часто злоупотребляют, поскольку код, который они создают, кажется умным и компактным.
Фактически они делают код менее читаемым и более подверженным ошибкам. По возможности рекомендуется использовать более длинную версию
if ( <condition> ) {
<action> ;
}
вместо тернарного синтаксиса.
Мне кажется, это нормально (я часто использую тернарный оператор Python), но такого рода вопросы стиля обычно очень субъективны. Если в проекте есть документ стиля кодирования, вы можете проверить это.
Я предпочитаю второй, потому что он более четко выражает то, что вы имеете в виду: вы хотите изменить цвет, только если он не равен нулю. Первый метод не делает это настолько ясным.
In В вашем случае я бы предпочел «классическую» реализацию, потому что мне легче понять, что вы хотите использовать новый цвет только в том случае, если у человека есть предпочтительный.
Я иногда использую его в вызовах методов, если я хотите избежать NPE,