Java 메소드 이름이 너무 긴 경우는 언제입니까? [닫은]

지난 몇 주 동안 메소드 또는 클래스 (50 문자)에 실제로 긴 이름을 사용하는 일부 사람들을 보았습니다. 이것은 일반적으로 가독성을 향상 시킨다는 전제 아래에 있습니다. 제 생각에 이와 같은 긴 이름은 우리가 긴 이름이 필요한 경우 메소드 클래스에서 많이 또는 너무 많은 것을 시도하지만, 나는 당신이 그것에 대해 어떻게 생각하는지 알고 싶었습니다.

예를 들면 다음과 같습니다.

getNumberOfSkinCareEligibleItemsWithinTransaction

메소드의 동작을 동일하게 전달하는 짧은 이름이 있으면 Java 또는 다른 언어로 된 이름이 너무 깁니다.

메소드 이름의 길이를 줄이는 몇 가지 기술 :

1. 전체 프로그램, 수업 또는 모듈이 '스킨 케어 아이템'에 관한 것이라면 스킨 케어를 떨어 뜨릴 수 있습니다. 예를 들어, 클래스가 호출 SkinCareUtils되면getNumberOfEligibleItemsWithinTransaction

2. 당신은 변경할 수 있습니다 내 에 있는 ,getNumberOfEligibleItemsInTransaction

3. Transaction을 Tx로 변경할 수 있습니다 getNumberOfEligibleItemsInTx.

4. 또는 메소드가 유형의 매개 변수를 허용 Transaction하면 InTx를 모두 삭제할 수 있습니다.getNumberOfEligibleItems

5. countOf에 의해 numberOf를 변경합니다 : getEligibleItemsCount

이제는 매우 합리적입니다. 그리고 60 % 더 짧습니다.

변경의 경우, 비 주관적인 답변 : 65536 자.

A.java:1 : 문자열 "xxxxxxxxxxxxxxxxxxxx ..."에 대한 UTF8 표현이 상수 풀에 비해 너무 깁니다.

;-)

나는 모든 사람들에게 동의합니다 : 메소드 이름은 너무 길어서는 안됩니다. 그래도 하나의 예외를 추가하고 싶습니다.

그러나 JUnit 테스트 방법의 이름은 길 수 있으며 문장과 유사해야합니다.

왜?

• 다른 코드에서는 호출되지 않기 때문입니다.
• 테스트 이름으로 사용되기 때문입니다.
• 그런 다음 요구 사항을 설명하는 문장으로 작성할 수 있기 때문입니다. (예를 들어, AgileDox 사용 )

예:

    @Test
    public void testDialogClosesDownWhenTheRedButtonIsPressedTwice() {
        ...
    }

이 아이디어에 대한 자세한 내용은 " 동작 기반 디자인 "을 참조하십시오 .

컨텍스트 "... IninTransaction"은 분명해야합니다. 이것이 객체 지향의 전부입니다.

이 메소드는 클래스의 일부입니다. 클래스가 "트랜잭션"을 의미하지 않는 경우-그리고 항상 "WithinTransaction"이라고 말하지 않아도된다면 문제가있는 것입니다.

나는 이름에 하이쿠 규칙 을 사용하는 경향이 있습니다 .

 Seven syllable class names 
 five for variables
 seven for method and other names

이들은 최대 이름의 경험 법칙입니다. 가독성을 향상시킬 때만 위반합니다. recalculateMortgageInterest (currentRate, quoteSet ...)와 같은 것이 recalculateMortgageInterestRate 또는 recalculateMortgageInterestRateFromSet보다 낫습니다. 속도와 따옴표가 포함되어 있다는 사실은 javadoc 또는 .NET과 같은 내장 문서에서 명확해야하기 때문입니다.

참고 : 실제 하이쿠는 아닙니다. 5-7-5가 아니라 7-5-7입니다. 그러나 나는 여전히 그것을 하이쿠라고 부르는 것을 선호합니다.

Java에는 긴 이름을 장려하는 문화가 있습니다. 아마도 IDE에는 자동 완성 기능이 우수하기 때문일 것입니다.

이 사이트에 따르면 JRE에서 가장 긴 클래스 이름 InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState은 92 자입니다.

가장 긴 메소드 이름 supportsDataDefinitionAndDataManipulationTransactions은 52 자입니다.

작은 것이 할 때는 긴 단어를 사용하지 마십시오.

"메소드 이름의 길이는 메소드의 길이에 비례합니다"라는 논문이 실제로 물을 담고 있다고 생각하지 않습니다.

"getNumberOfSkinCareEligibleItemsWithinTransaction"예제를 보자. 그것은 한 가지 일을하는 것처럼 들립니다. 특정 범주에 속하는 트랜잭션의 항목 수를 계산합니다. 물론 메서드의 실제 코드를 보지 않고 판단 할 수는 없지만 좋은 방법 인 것 같습니다.

다른 한편으로, 나는 "processSale"이나 인기있는 "doStuff"와 같이 많은 일을하는 매우 짧고 간결한 이름을 가진 많은 방법을 보았습니다.

메소드 이름 길이에 대해 단단하고 빠른 규칙을 제시하는 것이 어렵다고 생각하지만 목표는 함수의 기능을 전달할만큼 길고 읽을 수있을 정도로 짧아야한다는 것입니다. 이 예에서는 "getSkinCareCount"가 충분했을 것입니다. 문제는 당신이 구별해야 할 것입니다. 트랜잭션에서 스킨 케어 대상 항목을 계산하는 함수와 다른 스킨 케어 대상 항목을 계산하는 함수가 있으면 "ininTransactions"가 값을 추가합니다. 그러나 거래 외부에서 그러한 품목에 대해 이야기 할 것이 없다면, 그러한 불필요한 정보로 이름을 어지럽히 지 않아도됩니다.

둘째, 관리 가능한 길이의 이름이 가장 사소한 경우를 제외하고는 그 기능이 정확히 무엇인지 알려줄 것이라고 생각하는 것은 비현실적이라고 생각합니다. 현실적인 목표는 독자에게 실마리를 제공하고 나중에 기억할 수있는 이름을 만드는 것입니다. 예를 들어, 워프 속도에 도달하기 위해 소비해야하는 반물질의 양을 계산하는 코드를 찾으려고하는 경우, 함수 이름을보고 "calibrateTransporter", "firePhasers"및 "calcAntimatterBurn"을 보면 매우 분명합니다. 처음 두 가지는 그렇지 않지만 세 번째는 아닐 수도 있습니다. 내가 실제로 찾고있는 것을 확인하고 발견하면 내일 다시이 문제를 해결하기 위해 돌아올 때 더 쉽게 기억할 수 있습니다. 충분합니다.

세 개의 긴 이름은 비슷한 이름보다 짧은 이름보다 더 혼동됩니다. "calcSalesmanPay"와 "calcGeekPay"라는 두 가지 기능이 있다면 어느 것을 한 눈에 파악할 수 있을지 추측 할 수 있습니다. 그러나 "calculateMonthlyCheckAmountForSalesmanForExportToAccountingSystemAndReconciliation"및 "calculateMonthlyCheckAmountForProgrammersForExportToAccountingSystemAndReconciliation"이라고하는 경우 이름을 연구하여 어느 것이 어떤 것인지 확인해야합니다. 이러한 경우 이름에 포함 된 추가 정보가 비생산적인 것일 수 있습니다. 0.5 초의 사고를 30 초의 사고로 바꿉니다.

원하는 방식으로 인터페이스를 설계하고 구현을 일치 시키십시오.

예를 들어, 아마도 다음과 같이 쓸 것입니다.

getTransaction().getItems(SKIN_CARE).getEligible().size()

또는 Java 8 스트림을 사용하는 경우 :

getTransaction().getItems().stream()
    .filter(item -> item.getType() == SKIN_CARE)
    .filter(item -> item.isEligible())
    .count();

내 규칙은 다음과 같습니다. 이름이 너무 길어 자체 줄에 표시되어야하는 경우 너무 깁니다. (실제로 이것은 거의 20 자 이상임을 의미합니다.)

이것은 보이는 코드의 가시적 인 수직선의 수가 코딩 속도 / 효과와 양의 상관 관계가 있음을 보여주는 연구에 근거합니다. 클래스 / 메서드 이름이 크게 아프기 시작하면 너무 깁니다.

메소드 / 클래스가 선언 된 곳에 주석을 추가하고 그것이 무엇인지에 대한 긴 설명을 원한다면 IDE가 당신을 데려가도록하십시오.

방법 자체의 길이는 아마도 너무 많은 일을하고 있는지 여부에 대한 더 나은 지표 일 것입니다. 간결성을 위해 노력해야하지만 설명이 더 중요합니다. 더 짧은 이름으로 같은 의미를 전달할 수 없다면 이름 자체는 괜찮을 것입니다.

다음에 메소드 이름을 쓰려고 할 때, 다음 인용문을 생각하십시오.

"The man who is going to maintain your code is a phyco who knows where you stay"

해당 메소드 이름이 너무 깁니다. 그런 크기의 메소드 이름을 읽을 때 내 마음이 방황하는 경향이 있습니다. 공백없이 문장을 읽는 것과 같습니다.

개인적으로, 나는 가능한 적은 방법으로 단어를 선호합니다. 패키지와 클래스 이름이 의미를 전달할 수 있으면 도움이됩니다. 클래스의 책임이 매우 간결한 경우 거대한 메소드 이름이 필요하지 않습니다. 왜 "WithinTransaction"이 있는지 궁금합니다.

"getNumberOfSkinCareEligibleItemsWithinTransaction"은 다음이 될 수 있습니다.

com.mycompany.app.product.SkinCareQuery.getNumEligibleItems ();

그런 다음 사용시 메소드는 "query.getNumEligibleItems ()"처럼 보일 수 있습니다.

이름이 짧을수록 전체 프로그램 또는 프로그램의 중요한 부분에서 코드를 더 잘 읽을 수 있도록 변수 이름이 너무 깁니다.

이름이 길면 값에 대한 자세한 정보를 전달할 수 있습니다. 그러나 이름이 너무 길면 코드가 복잡해지고 나머지 코드를 이해하는 기능이 줄어 듭니다. 일반적으로 줄 바꿈이 발생하고 다른 코드 줄이 페이지 밖으로 밀려납니다.

트릭은 더 나은 가독성을 제공 할 것인지 결정하는 것입니다. 변수가 짧은 공간에서 자주 또는 여러 번 사용되는 경우 짧은 이름을 지정하고 설명을 명확하게하는 것이 좋습니다. 독자는 주석을 쉽게 참조 할 수 있습니다. 변수가 프로그램 전체에서, 종종 매개 변수로 또는 다른 복잡한 작업에서 자주 사용되는 경우, 이름을 잘라내거나 약어를 독자에게 상기시켜주는 것이 가장 좋습니다. 의미를 잊어 버린 경우 항상 변수 선언으로 주석을 참조 할 수 있습니다.

코드 리더가 이해하려고하는 것을 고려해야하고 시간이 지남에 따라 코드가 어떻게 변경되고 커지는 지 고려해야하기 때문에 이것은 쉬운 거래가 아닙니다. 그렇기 때문에 이름을 지정하기가 어렵습니다.

가독성은 DescriptiveLoopCounterName 대신 i를 루프 카운터로 사용하는 것이 허용되는 이유입니다. 이것이 변수에 가장 일반적으로 사용되므로 변수가 존재하는 이유를 설명하는 최소한의 화면 공간을 사용할 수 있습니다. 더 긴 이름은 루프 조건을 테스트하거나 배열로 인덱싱하는 방법을 이해하기 어렵게하여 시간을 낭비하게됩니다.

스펙트럼의 다른 쪽 끝에서, 다중 매개 변수 함수 호출로 전달되는 것과 같이 복잡한 연산에서와 같이 함수 나 변수가 거의 사용되지 않으면 지나치게 설명적인 이름을 지정할 수 있습니다.

다른 언어와 마찬가지로 더 이상 기능이 수행하는 단일 작업을 설명하지 않습니다.

나는 좋은 대답의 조합을 사용하고 합리적이라고 말하고 싶습니다.

이 방법의 기능을 완전하고 명확하며 읽기 쉽게 설명하십시오.

분석법 이름이 너무 길면 덜 수행 할 수 있도록 분석법을 리 팩터하십시오.

메소드 이름이 다른 라인으로 랩핑되고 메소드에 대한 호출이 라인의 유일한 항목이고 여백에 매우 가깝게 시작하는 시간이 너무 깁니다. 당신은 그것을 사용할 사람들의 평균 화면 크기를 고려해야합니다.

그러나! 이름이 너무 길면 너무 길 것입니다. 이 문제를 해결하는 방법은 컨텍스트 내에 있고 이름이 짧지 만 다른 컨텍스트에 복제되는 방식으로 코드를 작성하는 것입니다. 이것은 누군가의 이름 대신 영어로 "그녀"또는 "그녀"라고 말할 수있는 것과 같습니다.

그것이 무엇에 관한 것인지 너무 설득력있게 설명 할 때 너무 깁니다.

예를 들어 이러한 이름은 기능적으로 동일합니다.

자바에서 : java.sql.SQLIntegrityConstraintViolationException

파이썬 / 장고에서 : django.db.IntegrityError

SQL / db 패키지에서 몇 가지 유형의 무결성 오류가 발생할 수 있습니까? ;) db.IntegrityError충분하다.

Java 컴파일러가 처리 할 수있는 길이를 초과하면 식별자 이름이 너무 깁니다.

여기에는 두 가지 방법 또는 견해가 있습니다. 하나는 메소드가 수행하는 작업을 설명하기 위해 가능한 한 설명적인 한 (메소드 모범 사례 기본 규칙) 메소드 이름의 길이에 상관이 없다는 것입니다. 반면에, flybywire 게시물에 동의합니다. 우리는 지능을 사용하여 가능한 한 방법 이름을 줄이려고 노력하지만 설명을 줄이지 않아야합니다. 설명이 더 중요합니다 :)

다음과 같은 경우 이름이 너무 깁니다.

• 읽는 데 1 초 이상 소요
• JVM에 할당 한 것보다 많은 RAM을 차지합니다.
• 터무니없는 이름인가
• 짧은 이름이 완벽한 의미라면
• IDE에서 둘러 싸인 경우

솔직히 그 이름은 개발자에게 공개 API 메소드로 활용하거나 떠날 때 코드를 유지해야하는 개발자에게 그 목적을 전달하기 만하면됩니다. 키스 만 기억해