Статьи

Неэффективная Java

Ноябрь 10, 2018

Возможно, меня заменит робот для проверки кода. Есть некоторые отзывы, которые я повторяю снова и снова. Вот некоторые из моих наименее любимых:

Общая структура кода

Брось остальное

Когда if заканчивается return else является излишним и создает ненужные отступы.

01
02
03
04
05
06
07
08
09
10
11
if (foo) {
   return bar;
} else {
   return baz;
}
 
// should be replaced by
if (foo) {
   return bar;
}
return baz;

Массив -> Список -> Поток

1
2
3
4
5
6
List< ... > list = Arrays.asList(someArray);
list.stream(...)
 
// should be replaced by
 
Arrays.stream(someArray)

Тестовый код

Прежде чем это тяжелый инициализатор

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
// this is part 1 of two
private MyService myService;
 
@Before
public void before() {
    // now initialize
    myService = new MyService().init(123);
}
 
// the above code can be expressed in the initializer
// and is simple to read there...
// if it threw exceptions or needed some more complex
// set up, it wouldn't be
 
// it's in one clear place where we know where to
// find it
private MyService myService = new MyService()
    .init(123);

Тестовые броски

01
02
03
04
05
06
07
08
09
10
11
12
@Test
public void someTest()
    throws IOException, JsonException {
}
 
// never bother with multiple or specific exception
// throws in tests nobody cares and it's just noise
// the test runner will catch anything!
 
@Test
public void someTest() throws Exception {
}

AssertJ для размера

1
2
3
4
5
// long-winded
assertThat(list.size()).isEqualTo(2);
 
// should be
assertThat(list).hasSize(2);

AssertJ для всего

Встроенные утверждения JUnit не так богаты, как предоставляемые AssertJ. Как минимум, я рекомендую использовать некоторую форму assertThat , чтобы в конечном итоге вы не использовали утверждение, которое немного слабовато для ситуации.

Ваш assertEquals — неправильный путь

В 60% случаев, когда я assertEquals код с assertEquals , порядок неверный. Подсказка: используйте AssertJ !!! Юнит не прав в этом! Мы должны читать слева направо.

1
2
3
4
5
// wrong:
assertEquals(something.getFoo(), 123);
 
// it's expected IS actual
assertEquals(123, something.getFoo());

Mockito Static Imports

1
2
3
4
5
// this is not normal
Mockito.verify(mock).called();
 
// static import all mockito methods
verify(mock).called();

Mockito Times (1)

1
2
3
4
5
6
7
// this is a tautology
verify(mock, times(1)).called();
 
// look at what verify(mock) does internally
// replace with
 
verify(mock).called();

Смотрите оригинальную статью здесь: Неэффективная Java

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

37
Share: