여러 개별 라이브러리를 사용할 때 코딩 스타일

C 라이브러리를 포함하여 여러 가지 코딩 스타일을 가진 여러 라이브러리를 사용하는 일부 C ++ 코드를 작업 중입니다. 사용 가능한 단계에 도달하면 공개 소스가됩니다. 하나의 버그를 수정하거나 하나의 기능을 추가하기 위해 코드를 확인하는 단기 기고자에게 가장 혼란을 줄 수있는 것은 무엇입니까?

• 때로는 사용되는 라이브러리의 일반적인 코딩 스타일과 일치하지 않더라도 전체 응용 프로그램에서 일관된 코딩 스타일을 유지하십시오.
• 라이브러리가 특정 모듈에서 많이 사용될 경우 해당 라이브러리의 일반적인 코딩 스타일 (즉, 라이브러리 자체 코드 및 문서에서 사용되는 코딩 스타일)을 준수하십시오.

나는 후자가 특정 라이브러리의 전문가가 일회성 기여를 쉽게 할 수있게하고 개발 중에 자습서 / 예제 코드를 쉽게 통합 할 수 있다고 생각합니다. 그러나 응용 프로그램 전체에서 코딩 스타일이 일치하지 않습니다. 각 접근법의 장단점은 무엇입니까?

나는 그것이 전체 프로젝트가 얼마나 큰지에 달려 있다고 생각합니다.

극단적으로, 1 Mloc 프로젝트가 있다고 가정 해 봅시다. 대규모 프로젝트의 경우 단일 개인이 관련된 모든 영역에서 "전문가"가 될 가능성은 낮습니다. 따라서이 경우 각 주요 구성 요소에 대한 기존 코드 스타일을 고수합니다. 새로운 개발자는 영역을 선택하고 배우며 코드 스타일이 다른 많은 다른 구성 요소를 볼 수 없을 것입니다.

프로젝트가 훨씬 작 으면 개인이 전체 코드베이스를 이해하게 할 가능성 이 높은 경우 지배적 인 코드 스타일을 선택하고 그에 충실합니다. 이 경우, 새로운 개발자가 프로젝트의 모든 영역에서 작업 할 가능성이 있기 때문에 전체 프로젝트의 일관성이 더 합리적이라고 생각합니다.

중간 규모의 프로젝트는 아마도이 결정을 내리기가 가장 어려울 것입니다. 이 경우 각 접근 방식에 대한 비용을 측정하고 장기적으로 가장 비용이 적게 드는 방법을 결정해야합니다. 과제는 중간 규모의 프로젝트가 일반적으로 완전한 스타일 리팩토링이 엄청나게 비싸게 보일 정도로 충분히 성장했다는 것입니다. 코드 트리 구조를 다시 살펴보고 특정 코드 스타일을 그룹화하기 위해 사물을 배열 할 수 있는지 확인할 수 있습니다.

어느 쪽이든, 최종 결정은이 패키지를 구성하는 팀에 달려 있습니다.

내 추론을 위로부터 바꿀 수있는 일부 특이 치 :

• 하나 이상의 모듈이 끔찍한 스타일을 가지고 있다면 더 큰 프로젝트에서도 그 스타일을 유지하는 것은 의미가 없습니다. 그렇습니다. 스타일은 주관적이지만, 당신과 동료 프로젝트 참가자들이 정말로 특정 영역이 흐르는 방식을 좋아하지 않는다면, 오래된 스타일을 핵화하고 더 나은 스타일을 부여하십시오.

• 모든 스타일이 합리적으로 서로 가깝다면 "새로운 방법이 있습니다"라고 선언하고 모든 새로운 코드와 중요한 리팩토링에 사용하는 것이 쉬울 것입니다. 이것은 리뷰에 약간의 고통을 줄 수 있지만, 내 경험상 대부분의 사람들은이 접근법에 적응할 수 있습니다. 또한 이전 코드가 어디에 있는지 알려주는 표시를 제공합니다.

• 때때로 언어에 추가 된 새로운 기능에 따라 스타일이 바뀝니다. C ++은 수년 동안 많은 기능을 선택했습니다. 필요에 따라 이전 스타일을 이러한 기능을 이용하는 새로운 스타일로 리팩토링하는 것이 좋습니다.

• 일부 라이브러리는 특히 관용적 접근 방식 또는 스타일을 가질 수 있습니다. 그렇다면 프로젝트의 나머지 부분과 충돌하더라도 해당 라이브러리의 스타일을 고수합니다. frobnosticators다른 프로젝트에서 일하는 사람이 귀하의 프로젝트에서 일할 가능성을 높이기위한 것입니다.

의견 중 일부는 명령형 및 객체 지향 스타일을 고려한 것으로 언급했습니다.

특정 스타일에서 "무거운"모듈은 모듈의 크기가 중간 이상인 경우 계속 유지해야합니다. 저는 세 가지 주요 스타일 (제 국적, 객관적 및 기능적)을 다루었으며 무거운 명령형 스타일을 OO 스타일로 리팩토링했습니다. 코드가 중간 이상이면 리팩토링이 (예외적으로) 어려울 수 있습니다. 리팩토링을 지원하는 툴링 지원이 없었기 때문에 경험이 혼란 스러웠습니다.

필연적으로 스타일이 지정된 모듈과 특정 개발 틈새에 관용적 인 모듈 사이에 높은 상관 관계가 있다고 생각합니다. 이는 특이 치로 제기 한 마지막 지점으로 돌아갑니다. 따라서 해당 기능에 대한 모든 모듈은 다음과 같이 보일 것이며 해당 도메인의 전문가가 프로젝트에서 쉽게 작업 할 수 있기를 바랍니다. 그러나 옵션이 있고 팀이 해당 모듈의 스타일을 좋아하지 않는다면 옵션을 조사 할 것입니다.

마찬가지로, 나는 OO 원칙이 너무 멀리 취해 잘못 사용 된 무거운 OO 스타일 모듈로 작업했습니다. 예를 들어, 인터페이스는 다중 상속을 대신하여 사용되었습니다. 그리고 당신이 예상 한대로, 그것은 조잡한 구현이었습니다. 해당 모듈을 리팩토링하는 데 합당한 진전을 이룰 수 있었지만 대신 더 나은 패키지를 사용하는 대신 그 접근 방식을 포기했습니다.

고려해야 할 여러 레이어가있는 것처럼 들립니다.

1. 기존 라이브러리 및 수정 사항
2. 해당 라이브러리에 대한 새로운 단위 테스트 코드.
3. 추상화 계층.
4. 추상화 계층에 의해 제시된 API.
5. 추상화 계층을 사용한 예제 및 테스트 코드.

모든 코드를 공통 스타일로 미리 리팩터링하는 것이 합리적이지 않다고 가정합니다.

차례로 차례로 복용 :

1. 기존 코드베이스의 경우 해당 스타일을 고수하고 싶을 것입니다.
2. 기존 코드의 새로운 단위 테스트 코드는 특히 오래된 코드와 얼마나 많이 통합되어 있는지에 따라 회색 영역에 있습니다. 그러나 아마도 '선호하는 스타일'로 만들려고합니다.
3. 추상화 계층의 새로운 코드. 이것이 실제로 별도의 코드 계층임을 보장함으로써 코드가 기존 스타일과 많은 인터페이스를 수행하더라도 선호하는 스타일을 사용하는 데 어려움이 없어야합니다. 대부분의 코드는 다른 스타일과의 인터페이스가 필요하며이 문제를 결코 발견하지 못했습니다.
4. 분명히 API 자체는 가장 많은 생각이 필요하고 최대 유용성 요구를 충족시킵니다.
5. 모든 예제 또는 테스트 코드는 선호하는 스타일로 작성 될 수 있어야합니다. 추상화의 완전성에 따라 (즉, 하위 레이어를 완전히 숨기고 있는지 여부), 이는 쉽지 않거나 어려울 수 있습니다. 물론 미래의 클라이언트 코드를 읽을 수있게하는 것이 주요 목표 중 하나가 될 것입니다.

개인적으로 찾은 몇 가지 큰 레거시 코드베이스는 다음과 같습니다.

• 선호하는 스타일을 설정하고 코드 변경을 시행한다고해서 모든 이전 코드가 새 스타일로 이전되는 것은 아닙니다.

• 대부분의 엔지니어는 주어진 라이브러리에서 기존 스타일을 코딩하는 경향이 있습니다. 그렇지 않으면 많은 시행이 필요합니다.

• 레거시 라이브러리에서 선호하는 스타일을 요구하면 해당 라이브러리에서 스타일이 많이 일치하지 않는 경향이 있습니다. 따라서 코드 견고성과는 대조적으로 프리젠 테이션과 관련된 표준의 경우 표준을 요구하는 데 많은 이점이 있습니다.

마지막 문제 (약간 주제가 아니지만 관련성이 있다고 생각합니다)로서, 일부 엔지니어는 자신이 가장 잘 알고있는 스타일 이외의 다른 스타일 표준을 고수하려고 애 쓰고 있습니다. 스타일 결정에 팀을 참여시키고 구매를 확인하는 것이 좋습니다. 그렇게하면 실제로 혼합 코드에서 표준을 적용 할 수있는 훨씬 나은 위치에있게됩니다.

많은 타사 모듈로 대규모 프로젝트를 개발하는 경우 @MetaFight에 동의합니다.

문제를 실제 단어 문제와 함께 설명해 보겠습니다 . " 집에 조용한 생활 양식이 있다고 가정 해 봅시다. 조용한 곳을 좋아하고 더 큰 소리로 말하지 않으며 가족 구성원과 달리 그렇게하지 마십시오. 매일 다른 사람들이 당신의 집을 위해 무언가를 가져와야 할 필요가 있습니다. 그렇지 않으면 그들은 또한 낮은 목소리로 말할 것입니다. 작업을 수행 할 수있다. "멍청한 예를 ... 롤

그러나 필자의 요점은 원래 코딩 스타일을 유지하는 래퍼를 통해 이러한 라이브러리를 사용하는 방식으로 코딩 표준에 따라 해당 라이브러리에 대한 래퍼를 만드는 것입니다.

MetaFight의 경우 +1

프로젝트 전체에서 최소한의 혼동으로 단일 코딩 스타일을 사용하게 될 것입니다. 코딩 스타일을 사용하는 첫 번째 요점은 코드를보다 쉽게 ​​읽고 수정할 수 있도록하는 것입니다.

라이브러리에서 내부적으로 사용되는 코드 스타일은 관련이 없다고 생각합니다. 라이브러리가 너무 필수적이라면 OO 래퍼를 작성하는 것이 좋지만 라이브러리의 예제 또는 내부와 동일한 코드 스타일을 사용할 필요는 없습니다.