일반적으로 허용되는 코드 서식 지침은 무엇입니까?

Question

McCall의 품질 모델 에 따르면 제품 개정 은소프트웨어 제품의 품질 속성을 설명하기위한 세 가지 주요 관점 중 하나입니다.제품 개정 관점에서 유지 보수 가능성 , 결함을 찾아 수정하는 능력 은 소프트웨어 개정 능력에 영향을 미치는 핵심 품질 요소로 식별됩니다.

확실히 수정 과정의 어느 시점에서 사람의 참여, 특히 프로그래머의 참여가 필요합니다.코드의 형식은 프로그래머가 소프트웨어를 효과적이고 효율적으로 수정하는 능력에 영향을줍니다.

코드 수정 프로세스에서 프로그래머의 효율성과 효율성을 극대화하기 위해 일반적으로 허용되는 언어에 구애받지 않는 코드 형식화 가이드 라인은 무엇입니까?

Answer 1

지금까지 작업 한 최고의 가이드 라인은 일관성입니다.수년에 걸쳐 여러 팀에서 다양한 스타일을 사용해 왔습니다 ... 제가 본 최고의 결과는 스타일에 관계없이 전체 팀이 동일한 스타일을 사용하도록 강요 당했을 때입니다 :-)

Answer 2

언어에 구애받지 않는 개념에 대해 몇 가지 생각이 있습니다.

1.) 데드 코드 제거. 절대적으로 필수적인 것이 아니라면 주석 처리 된 데드 코드를 제거해야합니다. 루틴을 복잡하게 만들고 일부 문자열을 검색 할 때 종종 오 탐지가 발생하며 전문 개발자에게 좋지 않은 일반적인 엉성함을 보여줍니다.

2.) 유지 보수 수정의 경우, 일종의 결함 추적 시스템이 있다고 가정하고 설명에 결함 추적 번호를 참조하십시오. 이렇게하면 작업을 유지 관리하는 사람이 코드가 개정판간에 변경된 이유를 쉽게 파악할 수 있습니다.

3.)이를 지원하는 언어의 경우 처음 사용할 때와 최대한 가깝게 변수를 선언합니다.

언어에 구애받지 않는 몇 가지 다른 개념이 있다고 확신하지만 처음 떠오르는 몇 가지 개념입니다. 내가 아는 한, 특정 언어가없는 코딩 표준을 논의하는 것은 상대적으로 어렵습니다. 위의 다른 답변에도 동의합니다. 가장 좋은 스타일은 일반적으로 기존 스타일과 가장 완벽하게 조화를 이루는 스타일입니다.

Steve McConnell의 코드 완성 을 살펴볼 수 있습니다. 프로그래밍 언어에 관계없이 거의 모든 개발 상황에 적용 할 수있는 좋은 아이디어로 가득 차 있습니다.

Answer 3

일관성이 핵심입니다.가이드 라인을 어딘가에 기록하고 준수를 요구합니다.

코드 형식화는 걱정하거나 논쟁 할 가치가 없습니다.몇 가지 규칙을 만들고 준수하세요.

Answer 4

저는 Joel에 동의합니다.많은 스타일의 예가 있습니다.대부분이 좋습니다.일부는 더 이상 다른 것 (헝가리 표기법?)만큼 유용하지 않습니다.하지만 요점은 일관성입니다.새로운 개발자가 각 개발자의 개인 스타일에 익숙해지지 않고 즉시 코드를 이해할 수있는 한 작동합니다.

매년 정도 표준을 바꾸는 것은 아마도 나쁜 생각 일 것입니다.

Answer 5

Joel의 의견에 동의합니다. 조직 내에서 일관성을 유지하면 유지 관리 가능성이 상당히 높아집니다.다른 팀에 합류하면 모든 "내부 컨텍스트 전환"없이 코드를 훨씬 빠르게 읽을 수 있기 때문에 모든 것이 내 현재와 비슷한 모양과 느낌을 가지면 램프 업 시간이 훨씬 짧아집니다._var "/ etc 대신 mVar

Answer 6

우리가 가지고있는 가장 큰 표준 중 하나는 가변 "접두사"입니다.여기 오기 전까지는 주로 솔로를 썼기 때문에 걱정하지 않았습니다.

우리는 변수의 이름을 나타내는 접두사를 사용하여 변수의 이름을 지정해야합니다.따라서 dpVarName을 보면 double에 대한 포인터이고 lVarName이 long int라는 것을 즉시 알 수 있습니다.

처음에는 브라케팅 블록에 대해 두 가지 선택을하게되어 기뻤지 만 이제는 우리 모두가 한 가지 방법으로 만 수행했으면합니다.