Стоит ли делать пустую строку постоянной?

Question

У меня есть сотрудник, который клянется

//in a singleton "Constants" class
public static final String EMPTY_STRING = "";

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

if (Constants.EMPTY_STRING.equals(otherString)) {
    ...
}

вместо

if ("".equals(otherString)) {
    ...
}

Я говорю, что это

1. не стоит - не экономит место в пуле кучи / стека / строк
2. некрасиво
3. злоупотребление классом констант.

Кто здесь идиот?

Answer 1

Время от времени в .NET появляется один и тот же аргумент (где уже есть статическая строка поля только для чтения. Пусто). Это дело вкуса - но лично я нахожу "" менее навязчивым.

Answer 2

Хе-хе, забавная вещь: После компиляции вы не увидите разницы (в байт-коде) между «static final» и строковым литералом, поскольку Java-компилятор всегда вставляет «static final String» в целевой класс. Просто измените вашу пустую строку на что-то узнаваемое (например, LGPL-текст) и посмотрите на полученный файл кода * .class, который ссылается на эту константу. Вы найдете ваш текст скопированным в этот файл класса.

Answer 3

Мы просто делаем следующее для таких ситуаций:

public class StaticUtils
{
    public static boolean empty(CharSequence cs)
    {
        return cs == null || cs.length() == 0;
    }

    public static boolean has(CharSequence cs)
    {
        return !empty(cs);
    }
}

Тогда просто import static StaticUtils.*

Answer 4

Если вы все хотите хранить «пустые» строки в столбце пустых строк в Oracle, вам придется изменить определение EMPTY_STRING, чтобы оно отличалось от «»! (Я помню, как в прошлый раз, когда я был вынужден использовать Oracle, он не знает разницы между пустой строкой и пустой строкой).

Однако это должно быть сделано на уровне доступа к данным, чтобы остальная часть приложения не знала об этом, и / или не разбиралась в модели данных, чтобы вам не нужно было хранить пустую строку И пустые строки в одном столбце .

Answer 5

Почему предпочтительно использовать String.Empty в C # и, следовательно, общедоступную константу в других языках, заключается в том, что константы являются статическими, поэтому занимают только один экземпляр в памяти.

Каждый раз, когда вы делаете что-то вроде этого: -

stringVariable = "";

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

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

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

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

Поскольку инициализация строки распространена, рекомендуется сделать следующее: -

const String EMPTY_STRING = "";
String variable1 = EMPTY_STRING;
String variable2 = EMPTY_STRING;
String variable3 = EMPTY_STRING;
String variable4 = EMPTY_STRING;
String variable5 = EMPTY_STRING;

Вы создали 5 строковых указателей, но только 1 строку

вместо: -

String variable1 = "";
String variable2 = "";
String variable3 = "";
String variable4 = "";
String variable5 = "";

Вы создали 5 строковых указателей и 5 отдельных нулевых строк.

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

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

Кроме того, он менее подвержен ошибкам, так как "" и "" оба компилируются, но вы можете пропустить случайно добавленное место, которое может привести к ложным ошибкам времени выполнения, например, условной логике, такой как: -

myvariable = " ";
While (myVariable == ""){
 ...
}

Код внутри блока while недоступен, поскольку myVariable не будет удовлетворять условию на первой итерации. Ошибка инициализации с "" вместо "" легко пропустить, тогда как: -

myvariable = EMPTY_STRING;
While (myVariable == EMPTY_STRING){
 ...
}

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

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

public static class StringConstants{
    public static String Empty = "";
    public static String EMail = "mailto:%s";
    public static String http = "http://%s";
    public static String https = "https://%s";
    public static String LogEntry = "TimeStamp:%tYmdHMSL | LogLevel:%s| Type:%s | Message: '%s'";

}

String myVariable = StringConstants.Empty;

Вы даже можете расширить собственный объект String, в зависимости от вашего языка.

Answer 6

Хм, правила верны, но воспринимаются в другом смысле! Давайте посмотрим на причину, во-первых, все ссылки на объекты в java проверяются с помощью equals (). Ранее на некоторых языках это делалось с помощью оператора '==', если случайно кто-то использовал '=' для '==', катастрофы. Теперь вопрос магических чисел / констант, для компьютера все константы / числа похожи. Вместо 'int ONE = 1' можно, конечно, использовать 1, но будет ли это справедливо для двойного PI = 3,141 ...? Что произойдет, если кто-то попытается изменить точность позже.

Если бы мы пришли к контрольному списку, каково было бы правило в отношении общего руководства, не так ли? Все, что я хочу сказать, это то, что правила должны помогать, мы, безусловно, можем изменить правила только тогда, когда знаем их очень хорошо. Здравый смысл преобладает. Как предложил мой друг, программные константы, такие как 0/1, которые обозначают условия выхода, могут быть жестко запрограммированы, и, следовательно, принцип магического числа не применяется. Но для тех, кто участвует в логических проверках / правилах, лучше сохранить их как настраиваемые константы.

Answer 7

1. да - это не дает никакой выгоды.
2. зависит от того, к чему ты привык, я уверен.
3. Нет, это просто константа, а не злоупотребление.