최적화 코드에 주의할 만한 세부 사항

3575 단어
최근 수정 항목에서 일부 코드 위반 문제는 모두sonar가 검출한 것이다.많은 문제가 중복되어 나타나는데..그래서 지금 내가 비교적 중요하고 범하기 쉬운 문제들을 기록하고 있다.

저널


예를 들어 나는 slf4j를 사용한다면 클래스에서private static final Logger LOGGER = Logger Factory를 이렇게 성명해야 한다.getLogger(XXXX.class)
private static final 3개의 수식어는 모두 바꿀 수 없고 하나가 빠지면 안 된다.
LOGGER는 가능하거나 LOG로 바꿀 수 있으며 이 두 가지는 추천 문법입니다.
일부 클래스에서는 private final Logger logger = Logger Factory를 이렇게 쓰는 사람이 있습니다.getLogger(getClass())
이렇게 하는 것은 규범에 맞지 않는다.각 클래스의 인스턴스에 대해 Logger 클래스의 객체를 만들 필요가 없습니다.

집합이 비어 있는지 판단하기


집합이 비어 있는지 아닌지를 판단할 때 어떤 사람은list를 이렇게 쓴다.size() > 0 
이것도 규범에 맞지 않는다.규범화된 쓰기 방법은list입니다.isEmpty()
이렇게 하면 좀 더 간결하다.

Long 유형


만약 1개의 롱 값이 롱 대상으로 전환하는 것을 표시해야 한다면, 누군가는 이렇게 할 수도 있다.
이것은 최선의 선택이 아니다. 롱을 사용할 수 있다.Long은 cache가 있기 때문에 value Of (long) 로 대체합니다.
이 문장을 참고할 수 있다
 
또한 글자의 상수를 직접 사용한다면 L은 대문자로 써야 한다. 예를 들어 long num = 1L이 아니라 1L을 사용해야 한다.

Map 스트리밍


맵을 훑어보는 데는 여러 가지 방법이 있습니다.내가 줄곧 사용해 온 것은 가장 간단한 것이다.
for(String key : map.keySet()){

    String value = map.get(key);

}

하지만 사실 이것도 문제야.Entry 를 사용하는 것이 더 빠르지 않다는 것은 효율성 문제입니다.
대체 방법은
for(Map.Entry<String, String> entry : map.entrySet()){
    String value = entry.getValue();
    String key = entry.getKey();
}

문자열


어떤 때는 문자열을 연결해야 하는데, 지금은 여러분들이 스트링을 직접 사용하지 않을 거라고 생각합니다. 아마도 많은 사람들이 스트링 버퍼를 사용해서 대체할 것입니다.
이때 만약에 문자열을 연결하는 방법이 내부에 있다면 StringBuffer는 국부 변수로 존재하고 이때 동기화하는 문제가 없으면 StringBuilder를 사용하여 대체하여 더욱 좋은 효율을 얻을 수 있음을 주의해야 한다.

탭 및 공백


인코딩에 있어서 탭 대신 빈칸을 사용하는 것을 권장합니다. IDE는 탭을 자동으로 빈칸으로 바꿀 수 있습니다. 환경에 따라 탭 1개가 얼마나 줄어들었는지는 다소 다를 수 있지만, 빈칸은 같기 때문입니다.나는 탭이 빈칸보다 낫다고 생각하지만...마우스가 더 간단한 포지셔닝 코드를 만들 수 있기 때문에...그래도 이 규칙은 일리가 있는데...

if


단일if도 괄호가 필요합니다. 그렇지 않으면 다음에 코드를 추가할 때 틀리기 쉽습니다.eclipse는 코드를 포맷할 수 있어 검사하기 편리하지만 쓰는 것이 좋다

이상을 던지다


throw exception 때sonar는throw 당신이 직접 만든 exception이 높은 exception이 아니라는 것을 권장합니다. 이렇게 하면 도대체 무슨 잘못인지 판단하기 쉬울 것입니다.

문자열 비교


이 점은 약간의 업무 경험이 있는 친구들은 두 문자열을 비교할 때 상수를 앞에 써야 한다는 것을 잘 알고 있을 것이다.
문자열의 상수는null이 아니기 때문에 인용은null을 가리킬 수 있습니다.이렇게 하면 빈 바늘의 이상을 피할 수 있다.

메소드 매개변수


방법 매개 변수는 방법의 내부에서 가능한 한 수정을 피해야 한다. 그렇지 않으면 방법 밖의 인용에 영향을 줄 수 있다.
나는 개인적으로 Converter를 사용하여 매개 변수를 복사할 수 있다고 생각한다.

이상을 포착하다


이상을 포획한 후 이 이상을 기록하거나 다시 던지거나..아무것도 안 하는 게 아니라...그렇지 않으면 바깥쪽도 이곳에 이상이 있는지 모를 거예요.
catch 블록에throw에 새로운 이상이 생겨도 오래된 이상을 기록하는 것이 좋습니다.그렇지 않으면 원래의 사건 현장을 잃어버린 셈이다.
또한 ex.printStackTrace()를 사용하지 않는 것이 좋습니다.이상을 기록하는 데는 LOGGER를 사용해야 한다. 이 이치와 시스템을 사용하지 말아야 한다.out.print는 역시 LOGGER를 사용하듯이.

문자열과 숫자 비교


만약 문자열의 정수가 1개라면, 1개의 숫자와 비교하고 싶다면, 아마도 누군가가 이렇게 쓸 것이다.
 
Integer.valueOf(string) < 2000

 
이렇게 해서 사실 불필요한 포장과 해체를 한 번 더 했어요.
value Of 방법은 PARseInt 방법을 사용하고 PARseInt 방법은 int를 되돌려줍니다. value Of는 Integer를 되돌려주기 때문에 int를 Integer로 포장합니다.
그리고 비교해 보면 Integer와 2000을 비교할 때 인트라베이스를 뜯는다. 그래서 쓸모없는 포장과 뜯기를 한 번 더 한 셈이다.
Integer를 사용할 수 있습니다.valueOf 대신 parseInt 메서드

집합과 그룹을 되돌려주는 방법은null로 되돌려주는 것을 최대한 피합니다


가능하다면 null 대신 빈 집합과 그룹을 되돌려주는 것을 고려할 수 있습니다.
null 대신 new Array List () 로 돌아가기
왜냐하면 몇몇 지역에서는 다른 사람들이 수조와 집합을 두루 훑어보는 것은foreach의 형식을 채택하는 것이지 간단한 for를 채택하는 것이 아니기 때문이다
이런 상황에서null을 누비면 이상이 발생하지만, 빈 집합과 그룹을 누비면 발생하지 않습니다.
 
이상은 제가 최근에 느낀 점일 거예요.

좋은 웹페이지 즐겨찾기