Статьи

В и из кармана

Ноябрь 1, 2018

Я хотел бы обсудить один из моих многих лучших песен . Я люблю хорошие объяснительные переменные так же, как и следующий парень, и их учат в книгах, таких как Чистый код, как способ документировать ваш код лучше, чем комментарии… и это хорошо. В целом, мне нравится еще больше, когда объясняющая переменная заменяется поясняющей функцией для вычисления ответа, который вы бы сохранили в этой переменной, но это второй момент.

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

Рассмотрим этот код:

1
2
3
4
5
6
Report report = ReportBuilder.builder(TEXT)
    .format(CSV)
    .newlineFormat(CRLF)
    .build();
 
return report.generate(inputData);

Что такое report ? это объект отчета. Мы строим это и кладем в наш задний карман. Затем немедленно вынимаем его из заднего кармана и используем для генерации ответа для функции.

Это так же легко можно написать:

1
2
3
4
5
return ReportBuilder.builder(TEXT)
    .format(CSV)
    .newlineFormat(CRLF)
    .build()
    .generate(inputData);

Но где это говорит, что есть отчет? Это говорится в ReportBuilder в build и generate . Этот свободный стиль программирования предназначен для уменьшения количества выражений staccato того, что мы делаем с нашими объектами.

Не могли бы вы написать следующее?

1
2
3
4
5
boolean result = false;
if (input.contains("foo") && input.length < 10) {
    result = true;
}
return result;

Если это так, прекратите читать этот блог и найдите работу в том, что у вас хорошо получается.

1
2
// without the silliness
return input.contains("foo") && input.length < 10;

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

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

Я был виновен в том, что терпел слишком многое из этого:

1
2
3
4
5
ResponseObject object = httpClient.post(buildUrl(baseUrl, resourceEndPoint, PAGE, pageNumber, SORT, sortOrder),
    convertToJson(inputObject),
    getCredentialsHeaders(userName, password),
    shouldKeepAlive(keepAlive, numberOfActiveThreads),
    ResponseObject.class);

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

1
2
3
4
5
ResponseObject object = httpClient.post(url,
    body,
    credentials,
    keepAlive,
    ResponseObject.class);

Возможно, это поможет объяснить, что происходит в этом сложном вызове (хотя, что интересно, чем более бегло работает код, тем больше вы можете терпеть, просто оценивая вещи по ходу дела). Очевидно, что для выполнения этого вызова необходимы некоторые переменные. Это круто. Они частично объясняют, они частично разделяют проблемы.

Вы говорите, что вам нужно оценивать вещи несколько раз?

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

  1. Нет! — объясняющие переменные предназначены для однократного использования, любая другая переменная имеет другое назначение — либо аккумулятор, который собирает данные через функцию, либо эффективная константа, которая содержит ответ для повторного использования (хотя я не фанат чрезмерного использования final в Ява…)
  2. Посмотрите, сможете ли вы сконструировать свои функции так, чтобы они были такими маленькими, что им действительно не нужно было бы многократно использовать данные

Чтобы подвести итог

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

Это только пояснительная переменная, если она предоставляет контекст для данных, поэтому, если она просто названа в честь типа, это, вероятно, просто усилие чтения, а не помощь.

Смотрите оригинальную статью здесь: В и из кармана

Мнения, высказанные участниками Java Code Geeks, являются их собственными.

35
Share: