팀 내에서 Java 스타일 충돌


12

6 주 기한이있는 Java 개발 팀의 일원입니다. 이를 위해서는 많은 양의 코드를 매우 빠르게 작성해야합니다. 그러나 우리 개발 팀은 다른 스타일의 코딩을 가지고 있습니다. 이름 규약에서 추상화 방법에 이르기까지 모든 것은 팀마다 다릅니다. 누구나 Java에 대한 "표준"을 지시하는 문서를 알고 있습니까?

명확히하기 위해 변수 및 함수에 대한 적절한 명명 규칙을 지시하는 조직이 있는지 궁금합니다. 짧은 마감 시간으로 서로 코드를 이해하는 데 시간을 할애 할 수 없기 때문에 이는 매우 중요합니다.

답변:


18

Sun / Oracle 자체와 같은 조직이 있습니다. 이 문서를 Java 프로그래밍 언어에 대한 코드 규칙 이라고하며 필요한 대부분의 규칙에 대해 설명합니다. 모든 사람이 그것을 읽고 그 권고 사항을 따르기로 동의하십시오.


3
이것은 잘 알려진 표준이지만 팀이 동의하는 곳에서 벗어나는 것을 두려워하지 마십시오. 예를 들어 너비를 80 자로 제한하면 고통 스러울 수 있습니다.
Martijn Verburg

1
@MartijnVerburg의 한계는 들여 쓰기를 피하기 위해 메소드와 클래스로 리팩토링 할 수 있습니다.

이것은 컨벤션이며, 자체 계약을 찾을 수 없다면 이름이 명시하지 않지만 합의입니다.
사용자가 알 수 없음

@userunknown 당신이 맞아요. 나는 모든 협약에 동의하지도 않습니다. 그러나 영업 기간이 주어지면 좋은 타협입니다.
Andres F.

8

난 정말있어 안드레스의 대답에 태그 , 균일 자바 코드를 서식 측면에 초점을 맞춘.

Eclipse를 사용하는 경우 Java 포맷터가 Java 표준으로 자동 형식화되도록 설정할 수 있습니다. 이클립스 포맷터에는 줄당 문자 수 (예 : 줄당 문자 수를 줄 바꿈하기 전의 줄 수) 및 기타 여러 가지와 같은 유용한 설정이 있습니다. 줄당 문자를 표준화하면 간격 및 줄 바꿈과 큰 차이없이 다른 개발자가 작성한 코드를 더 쉽게 구별 할 수 있습니다.

마지막으로 Eclipse를 사용하여 원하는 모든 설정을 설정 한 후에는 모든 팀원이 가져올 수있는 파일로 포맷터를 내보내십시오. 따라서 Eclipse를 사용하는 경우 자동 형식화 및 코드 편집을 수행하는 모든 옵션을 완전히 탐색 한 다음 설정을 전체 팀과 공유하는 것이 좋습니다.

다른 주요 Java IDE (IntelliJ 및 Netbeans)에 형식 설정을 내보내는 비슷한 기능이 있다고 가정합니다.


2
+1 좋은 답변! Checkstyle 과 같은 플러그인을 설치하고 컨벤션을 위반했을 때 경고하도록 할 수도 있습니다.
Andres F.

우리도 마찬가지입니다. 환경 설정-> Java-> 편집기-> 저장 옵션 및 저장시 형식을 사용하십시오. 주된 이유는 포맷에 의해 영향을받는 소스 라인이 가능한 한 빨리 발생하여 버전 제어 히스토리를 가능한 한 깨끗하게하는 것입니다 (다시 차이점).

예, 최근 에도이 작업을 시작했습니다. 확실하지 않은 유일한 것은 저장 옵션에서 "사용하지 않은 개인 변수 제거"를 선택했다는 것입니다. TDD를 수행하는 동안 변수를 사용하기 전에 코드가 저장되어 변수가 사라지는 것을 자주 알지만이 옵션 이외의 다른 옵션은 훌륭했습니다.
Sam Goldberg

6

이 [다른 코딩 스타일]은 짧은 마감 시간으로 서로 코드를 이해하는 데 시간을 할애 할 수 없기 때문에 가장 중요합니다.

사실은. 가장 중요하지 않습니다.

컨설턴트로 삼십년 후, 나는 읽은 많은 많은 고객으로부터 코드를. 모든 고객 (및 종종 고객의 조직 내)에는 다양한 스타일이 있습니다.

많은 스타일을 읽은 후 나는 이것을 배웠다.

스타일은 중요하지 않습니다

항상 작동하는 코드 작성과 항상 작동 함을 입증하는 단위 테스트 작성에 중점을 두십시오.

작업 코드를 제공 한 후에는 버그 수정 및 설치 개선 기능이 부족한 경우이를 코드화 할 수 있습니다.


중요하지 않을 수도 있지만 가지고있는 것도 좋고 매우 쉽습니다.
Kevin

1
스타일은 중요하지 않지만 일관성은 중요합니다. 일관성이없는 스타일로 인해 소프트웨어 유지 관리가 훨씬 어려워집니다.
Jesper

5
@Jesper : "일관되지 않은 스타일로 인해 소프트웨어 유지 관리가 조금 더 어려워집니다". 어떤 스트레칭으로도 어렵지 않습니다. 불투명하고 나쁘고 버그가 많은 코드는 유지 관리하기가 훨씬 어렵습니다. 작업 코드에서 일관성이없는 스타일은 일관성이없는 스타일입니다. 어떤 사람들은 악센트를 가지고 있으므로 좀 더 신중하게 들어야합니다. 일치하지 않는 스타일은 다른 지역 (또는 국가) 악센트에 지나지 않습니다.
S.Lott

1
스타일은 전 세계적으로 중요하지 않지만 단일 팀 내에서 일관된 스타일 중요합니다. 프로젝트를 만들거나 깨뜨리지는 않지만, 일관성이없는 것처럼 쉬운 일이라면 왜 계속 일관되지 않습니까? 코드가 조금 더 나아질 것입니다.
Bryan Oakley 2012

1
"당신의 코드에있을 것입니다" 최고 "소폭 개선". 그리고 그렇습니다. 비용이 거의 들지 않고 확실히 위험이 없습니다. 그러나. 100 % 테스트 범위는 일관성보다 훨씬 더 중요합니다.
S.Lott

2

완벽한 범용 표준을 고르는 것에 대해 걱정하지 마십시오. 당신이 필요로하는 것입니다 당신의 팀에 동의 것이 표준 및 스틱. 원하는 경우 직접 구성하지만 일관성을 유지하십시오.

일관성은 협업을 향상시키고 협업은 코드를 향상시킵니다.

실제 일관성없는 도움을 할지라도, 당신의 팀이 근무한다는 사실 을 함께 합의에 와서 좋은 일이다. 코딩 컨벤션처럼 단순한 것에 동의 할 수 없다는 점은 표면에 더 큰 팀워크 문제가있을 수 있다고 말합니다.


0

위에서 언급 한 Sun Java CC는 13 세일뿐만 아니라 일부 규칙 (예 : 한 줄에 80 자)이 구식 일뿐 아니라 가장 일반적인 규칙 (클래스의 낙타 케이싱, 블록 대문자)을 제외하고 명명 규칙을 정의하지 않습니다. 정적 최종 변수 등).

DAO, EJB, 엔티티 등 사용하는 모든 유형 의 클래스에 대해 고유 한 표준을 정의해야 합니다. Sun Java CC는 확장을위한 추상 기본 클래스와 같습니다.


썬의 Java CC가 약간 오래되었다는 데 동의하지만 이는 시작점에 불과합니다. OP가 자체 CC를 정의하는 데 많은 시간을 할애하지 못한다고 가정합니다. (BTW, 현재 근무하는 곳 에서는 80 자 제한을 적용하도록 구성된 Sonar 플러그인 을 사용 하므로이 규칙은 여전히 ​​살아 있으며 일부 상점에서 시작됩니다).
Andres F.

다른 이유 외에도 가독성이 중요한 요소입니다. 한 줄을 가로 질러 원거리를 스캔하는 것은 스캔하는 것보다 훨씬 덜 효율적입니다. 올바른 형식의 코드를 사용하면 관련이없는 코드를 빠르게 스캔 할 수 있습니다.
BillThor

한 줄에 80 문자로 문제가 발생하면 식별자가 놀랍도록 길거나 한 줄에 읽을 수 없을 정도로 많이 넣었습니다. 전자는 어리 석고 (요점을 그 이하로 증류 할 수 없습니까?) 후자는 리팩토링이 시급한 필요성 을 나타냅니다 . 저장시 자동 서식은 더 이상 형식에 대해 걱정할 필요가 없으므로 훌륭합니다. 소프트웨어가이를 처리합니다.
Donal Fellows

@DonalFellows 그렇습니다. 요즘에는 80 개의 문자 제한으로 인해 작은 터미널 화면이 아니라 리팩토링해야합니다.
Andres F.

0

여기에서 다른 사람들이 언급했듯이 온라인에서 Java를위한 몇 가지 인기있는 '스타일 가이드'를 검색하고 팀의 모든 사람들이 그들을 고수하도록 설득 할 수 있습니다. 자주 사용하는 IDE의 일부 코드 검사 도구는 그렇게하지 않을 때이를 상기시키는 데 도움이 될 수 있습니다.

그러나 때때로 정치가 관련됩니다. 나는 한때 누군가가 표준화해야 할 필요성을 언급 한 후에도 팀의 최고 개발자가 계속 그렇게하는 상황에 처해 있습니다. 이러한 상황에서는 코드 기반과 요구 사항에 대해 가장 많이 알고 있기 때문에 코드 스타일을 관찰하고 따르는 것이 더 나을 수 있습니다. 어려울지라도 발가락을 밟는 데 시간을 낭비하고 싶지 않을 수 있습니다. 그것은 우리의 나머지 사람들이 그 특정한 상황에서했던 것입니다.

따라서 귀하의 상황도 고려해야합니다.


이것은 어느 나라입니까? 문화적인 것 같습니다.

@ ThorbjørnRavnAndersen 그는 사람들이 "그들이 오랫동안해온 일"에 변화가 생길 때 저항 할 수 있다고 말합니다. 이런 의미에서 정치는 단지 "사무실 정치"
Robotnik

0

Bob 아저씨는 그의 저서 "Clean Code"에서보다 현대적이고 현재의 코딩 스타일을 보여줍니다. 불행히도 항목 목록이 없습니다. 읽어야합니다. 그는 자신의 규칙을 보려면 자신의 코드를 읽어야한다고 스스로에게 말합니다. 밥 아저씨는 틀림없이 일종의 제도입니다. 이 책은 어쨌든 훌륭한 책이므로 지금 읽기에는 너무 늦었더라도 최대한 빨리 읽으십시오.


0

코드에서 실제로 중요한 것은 낮은 순환 복잡성, 작은 범위, 높은 응집력 및 표현 식별자의 선택입니다. 이러한 점을 감안할 때 코드를 파악하기 쉬워지고 코드가 좋습니다.

Spartan Programming 을 살펴 보시기 바랍니다 .

대부분의 코딩 표준은 잘못 작성된 코드를 예쁘게 보이게하는 방법을 알려주며 "코딩 스타일"에 대한 대부분의 논의는 실제로 서식에 관한 것입니다. 코드 형식은 코드 구조를 시각적으로 나타내는 것입니다. 코딩 스타일은 코드 구조를 나타내는 방법이 아니라 코드를 구성하는 방법에 관한 것이기 때문에 사소하고 자동화 가능하며 코딩 스타일과 거의 관련이 없습니다.
명명 규칙에 대한 많은 종교적 전쟁이 있지만 실제로는 열악한 디자인을 해결하기위한 해킹 일뿐입니다. 그것이 의미하는 바가 있다면 이름이 좋습니다. 범위가 작고 명확할수록 그러한 이름을 선택하는 것이 더 쉽습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.