개발자의 자율성을 위해 코딩 스타일을 권장해야합니까, 일관성을 위해 코딩 스타일을 권장해야합니까?


15

개발자는 다음 if/else과 같은 한 줄 코드 문장으로 블록을 작성 합니다.

if (condition)
   // Do this one-line code
else
   // Do this one-line code

다른 하나는 모두 중괄호를 사용합니다.

if (condition) 
{
   // Do this one-line code
}
else
{
   // Do this one-line code
}

개발자는 먼저 객체를 인스턴스화 한 다음 사용합니다.

HelperClass helper = new HelperClass();
helper.DoSomething();

다른 개발자가 한 줄로 객체를 인스턴스화하고 사용합니다.

new HelperClass().DoSomething();

배열과 for루프를 사용하면 개발자가 더 쉽습니다 .

string[] ordinals = new string[] {'First', 'Second', 'Third'};
for (i = 0; i < ordinals.Length; i++)
{
    // Do something
}

또 다른 글 :

List<string> ordinals = new List<string>() {'First', 'Second', 'Third'};
foreach (string ordinal in ordinals)
{
    // Do something
}

내가 무슨 말을하는지 확신합니다. 나는 그것을 코딩 스타일이라고 부릅니다 (왜 그것이 무엇인지 모릅니다). 그러나 우리가 무엇을 부르든 좋든 나쁘습니까? 그것을 장려하는 것은 개발자의 생산성 향상에 영향을 줍니까? 전체 시스템의 스타일 일관성을 유지하기 위해 개발자에게 코드를 작성하도록 요청해야합니까?


1
자동 코드 서식 도구를 사용할 수 있고 편리 할 때 이러한 도구를 실행하지 않고 (일관되지 않은 개인 스타일을 유지) 스타일을 적용하는 것이 더 중요합니까?
푹신한

일관된 스타일로 코드를 쉽게 읽을 수 있으므로 일관된 스타일을 사용하십시오. 귀하의 예에서 가장 읽기 쉬운 것은 2, 1, 2입니다. 마지막 경우는 다릅니다. 성능이 중요한 애플리케이션에서는 목록을 반복 할 때 for 루프가 더 빠릅니다. 어레이에서 반복되는 성능은 동일합니다. 모든 경우에 var정규화 된 유형 이름 대신 사용 하십시오.
Stephen

답변:


19

코딩 표준 문서가 유용합니다. 그것은의 대부분 은 사람이 너무 많은 문제없이 모든 일을 기억할 수있는 짧은만큼이 때 유용하고 사람 너무 많은 고통을 발생하지 않습니다 때.

조직에서 코드를 들여 쓰거나 이름을 대문자로 입력하거나 루프를 구현하거나 코드에 주석을 달는 방법은 그다지 중요하지 않습니다. 유용한 부분은 모든 사람이 다른 사람과 똑같이 보이는 코드를 작성하도록하는 것입니다.

  • 다른 사람의 코드를 볼 때마다 중괄호가 있어야 할 위치에 대한 기대치를 재보 정하는 데 1 분을 소비하지 않아도됩니다.
  • 동일한 파일에 여러 가지 스타일의 코드가 모두 포함되지 않도록합니다.
  • 아마도 가장 중요한 것은 표준을 작성하면 코드 검토 중에 코딩 방식에 대한 논쟁을 피할 수 있다는 것입니다.

다시 말하지만, 표준이 무엇인지는 단순하고 간단한 표준을 갖는 것만 큼 중요하지 않습니다. 따라서 모든 개발자를 한 방에두고 표준이 무엇인지 논쟁하도록하십시오. 이 회의는 무기한 진행될 수 있으므로 규칙은 다음과 같습니다.

  • 회의 종료시 결정되지 않은 사항은 관리자가 결정합니다.
  • 회의는 2 시간 후 또는 누군가 소리를 지르거나 울기 시작하면 둘 중 빠른 시간에 종료됩니다.
  • 전체 표준은 필요한 경우에만 양면 인 한 장 또는 두 장의 용지에 (합리적 유형 크기로!) 맞습니다.

누군가 입양 고려 | 다른 사람 | 표준 은 자체 코딩 표준 회의의 시작점으로 또는 회의를 완전히 피하는 방법으로 사용됩니다.

일단 합의하면 개발자는 스스로 경찰을 지을 수 있어야합니다. 때때로 표준에서 벗어난 편차는 큰 문제가되지 않아야하며 (또는 정당화 될 수도 있음), 표준을지지하기 위해 좋아하는 개인 스타일을 포기하는 것을 거부하는 경우에만 수도관이 새는 파이프 등으로 즉시 사무실로 이전해야합니다. .

데미안 브레히트 (Demian Brecht)는 보푸라기 도구를 가리 킵니다. 이들은 코딩 표준 문서를 완벽하게 보완합니다. 코딩 스타일 표준 을 고수하는 것이 좋습니다 . 그건 중요한 위험 관행과 관련 코딩 표준에 충실. 저자 이외의 다른 사람은 모든 코드 줄이 스타일 표준을 충족하는지 확인하지는 않지만 팀의 워크 플로에 보푸라기 도구를 작성하여 버그를 자동으로 잡는 것을 고려해야합니다. 또한 도구 자체는 승인 된 관행을 체계화하여 코딩 표준에 모두 개별적으로 나열 할 필요가 없습니다. 도구 구성 만 지정하면됩니다.

참고 : "코딩 표준"아이디어는 프로그래밍에 고유하지 않습니다. "코딩 표준"은 많은 분야에서, 때로는 조직 내에서, 더 자주 전체 산업 또는 직업에서 사용됩니다. 몇 가지 예 :

각각의 경우 (및 다른 많은 경우) 유능한 전문가는 예상 표준을 충족하지 않는 "코드"를 쉽게 이해할 수 있습니다. 컴파일러가 파싱 할 필요가없는 문서에 대한 자세한 요구 사항을 작성하는 데 왜 많은 산업이 계속 유지됩니까? 스타일이 중요 하기 때문 입니다 . 표준 스타일로 정보를 제시하면 독자는 내용에 전적으로 집중하고 더 빨리 읽고 이해하고 도움을주고 오류를 줄일 수 있습니다.


1
당신이 당신의 게시물에 linting 도구의 사용을 추가하면, 난 내 삭제됩니다 +1 당신 :
데미안 브레히트

@DemianBrecht, 좋은 제안, 감사합니다. 내 대답을 향상시키기 위해 보풀 도구를 추가했지만 당신도 당신을 떠나야한다고 생각합니다.
Caleb

그럼 괜찮아 +1 어쨌든 :)
Demian Brecht

그리고 당신에게도!
Caleb

내 경험에서와 같이 "... 즉시 재배치 ..."에 +1하면 그러한 행동은 소프트웨어 개발 팀과 호환되지 않는 사회 경로 및 / 또는 자기애 적 경향과 일치합니다.
mattnz

16

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

나는 말했다.

30 년 후, 수백 개의 클라이언트 사이트와 그 기간 동안 500 명 이상의 팀원이 작성한 코드는 그 스타일이 중요하지 않다는 것을 알게되었습니다.

먼저 작동 시키십시오.

최적의 리소스 양 (예 : 올바른 데이터 구조, 올바른 알고리즘)을 사용하도록하십시오.

다른 모든 것이 해결 된 후 "스타일"에 대한 소란 . 도구 만 사용하여 "스타일"의 소란을 피우십시오.


2
아멘! 코딩 표준은 실제 이점 측면에서 정당화되어야하며 일관성은 실제 이점이 아니라 사치입니다.
JohnFx

12
그러나 스타일은 거의 스타일에 관한 것이 아닙니다. 일반적인 오류를 피하는 것입니다.
Martin York

6
그러나 '=='대신 '='를 피하는 데 도움이됩니다 (조건 내에서 할당을 사용하지 마십시오). if (t) { x;y;}오히려 피하는 데 도움이됩니다 if (t) x;y;(if 후 항상 '{}'사용). const 올바른 코드를 선호하십시오 (코드가 작성된 후 코드에 const 정확성을 추가하는 것은 매우 어렵습니다. std :: cout / std :: cin 사용 fprintf / scanf를 사용하지 마십시오. 전자가 오류를 일으킬 가능성이 훨씬 높습니다. 배열보다는 벡터를 사용하십시오. (오버플로 방지)
Martin York

5
작동시키는 것이 가장 중요합니다. 그러나 그것이 효과가 있다고해서 반드시 끝난 것은 아닙니다. 또한 테스트해야합니다. 그런 다음 검토했습니다. 모두 며칠이 걸릴 수 있습니다. 그런 다음 몇 년 동안 읽고 이해하고 유지해야합니다. 유용한 코드 (왜 다른 종류의 코드를 작성해야합니까?)는 작성된 코드보다 여러 번 읽히 므로 읽기 쉽고 이해하기 쉽게 미래의 생산성을 향상시킵니다. 조직 전체에 일관된 스타일을 사용하는 것이 그러한 측면에서 도움이되는 한 가지 방법입니다.
Caleb

1
자동 서식 도구를 사용하는 것은 어떻습니까? Eclipse와 XCode를 사용하면 코드 형식을 매우 쉽게 유지할 수 있습니다. 그러나 내가 작업하는 엔지니어 중 한 명이 누군가가 "자신의"코드 (예 : 회사 코드)를 자동으로 포맷하여 나머지 코드베이스와 일관성을 유지하면 매우 화가 나게됩니다. 서식은 스타일의 작은 부분 일뿐 아니라 특히 if / else 중첩 및 전체 코드 흐름과 같은 문제 (가독성은 언급하지 않음)에 중요한 요소입니다.
솜털

4

코딩 스타일과 코딩 냄새가 있습니다. 내가 찾은 것은 한 번도 아니었다.

    if(debugCondition)
//         printf("DEBUG: state:%s at debugCondition\n",dbg_state());

    for(i=0; i<MAX;i++)
    {
       //some essential business logic
    }

저의 이전 고용주는 if()중괄호없이 여러 줄을 사용하는 것을 엄밀히 금지했습니다 . "다시 해고 해"유형 결함으로 간주되었습니다. 허용 된 구조는

     if(condition) break; 
     if(condition) continue; 
     if(condition) return; 
     if(condition) for()...; 

이것은 위에서 보여준 것과 같은 오류로 인해 포털의 메인 페이지를 중지시키는 데 몇 시간이 걸렸습니다.

항상해야 할 일이 있습니다. 좋아요 switch():

     case 1:
         something();
     break;
     case 2:
         something();
     return;
     case 3:
         something();
     continue;
     case 4:
     case 5:
         something();
     break;
     case 6:
         something();
     //fallthrough;
     case 7:
     ...

한편 다음을 입력하십시오.

     case 1:
         something();
     case 2:
         something();
     break;

casewith 를 닫지 않으면 //fallthrough버그로 간주됩니다.

일반적으로 주어진 요구에 따라 무시, 창의적으로 해석 또는 수정 될 수있는 가이드 라인 인 코딩 표준이 있습니다. 그리고 "냄새"에 대한 섹션이 있으며 엄격하게 준수해야합니다.


3

우수한 선행 설계로 일관성을 만듭니다. 질문에서 설명하는 것은 소량 관리에 지나지 않습니다. 나는 많은 웹 개발을한다. 따라서 서비스로 노출 된 RESTful 및 CRUD 개발을 선호합니다. 이를 통해 다양한 방법으로 사용할 수있는 간단하고 잘 정의 된 엔터티가 보장됩니다.

이 디자인을 통해 구현 세부 정보를 다른 개발자에게 위임 할 수도 있습니다. 이러한 방식으로 전체 시스템 설계를 작성하지 않고 공백을 채 웁니다.

전체 디자인이 부족하면 시스템 불일치가 발생합니다. 기본 반복과 루핑 구조에 대한 비판은 시스템 설계를 개선하는 데 거의 도움이되지 않습니다. 이러한 종류의 문제는 StyleCop이라는 수동 접근 방식으로 더 잘 해결됩니다 .

전반적인 시스템 설계의 비교적 간단한 다이어그램을 그릴 수 있습니까? 새로운 팀 개발자와 관련된 요소 / 엔터티를 설명하는 디자인입니다. 당신이 할 수 없거나 매우 관여한다면, 디자인은 부족하다.


3

IMHO 그것은 달려있다 ...

처음 두 가지 예는 단지 개인적인 취향의 문제가 아닙니다.

if (condition)
   // Do this one-line code
else
   // Do this one-line code

(괄호없이) = 나중에 더 많은 코드가 추가되면 버그가 발생하기 쉽습니다.

if (condition)
   // Do this one-line code
else
   // Do this one-line code
   // ...and this line as well... oops! this will actually execute either way

그리고 이것은 디버그하기가 덜 편리합니다.

new HelperClass().DoSomething(GetSomeData()); // etc.

필요한 곳에 중단 점을 설정할 수는 없습니다. 이것이 일회성-공평하지만 스타일 문제로 논의하고 모든 장소에서 이와 같은 것을 얻으면 디버깅이 필요 이상으로 불쾌 해집니다.

세 번째 예 (for foreach)는 맛의 문제라고 생각합니다.


2

둘 다. 나는 지루하고, 까다 롭고, 소극적이며 최악의 시간 낭비를 피하기 위해 가혹한 코딩 규칙을 피할 것입니다. 당신의 자율성은 당신 자신의 문제입니다. 당신이 자신에 대해 더 나은 느낌을 갖기를 원한다면, 나는 당신에게 가장 좋아하는 음료를 사줄 것입니다. 그 외에는 무언가를 해보십시오.


2

규칙, 변수 이름, 클래스 이름 등을 사용하는 것이 좋습니다. 그러나 제공하는 예제와 같은 코딩 스타일은 사소한 것이며 코드의 가독성이나 효율성에 영향을 미치지 않습니다. 한편, 개발자의 노력과 함께 주어진 스타일을 적용하는 데 따른 오버 헤드로 인해 문제가 발생할 수 있습니다.


2

업계 표준 보푸라기 도구 ( C # 용 FxCop )를 사용하십시오. 끝이 아닌 것은 아니지만 많은 사람들이 작업하는 대규모 프로젝트 에서는 일관성 중요합니다.

자신의 프로젝트 또는 소규모 팀에서 일하고 있다면 많은 사람들이 과도하다고 주장합니다. 나는 그렇지 않다고 생각합니다 ( 개인용 단일 개발자 프로젝트에서도 Python 용 PEP8 을 사용 합니다).

그러나 대부분의 예제는 단순히 문제가되지 않기 때문에 보푸라기 도구에 걸리지 않을 것입니다.


1

균일 한 코딩 스타일을 적용하는 것은 항상 어렵습니다. 이상적으로 이러한 일상적인 작업은 처리 할 도구에 맡겨야합니다. 나는 그렇게하는 것에 대해 Go language 공동체에 박수를 보냅니다.


1

둘의 혼합입니다. 표준이기 때문에 읽기 쉽고 유지 관리가 불가능합니다. 주입 된 표준이 없거나 표준에 결함이 있거나 읽을 수없는 측면이있는 경우 개정이 적합합니다.


1

최종 분석에서 프로그래밍을 주도하는 것은 프로그래머입니다. 스타일 문제는 존재하지만 프로그램을 내보내는 데는 부차적입니다.

프로그래머에게 몇 가지 스타일 지침을 제공하는 것이 도움이됩니다. 이것은 프로그래머가 작업을 시작하기 전에, 특히 환경에 대한 초보자이거나 프로그래밍 자체 인 경우 수행해야합니다. 지침이 주어지면 일부 프로그래머는 매우 스타일에 민감하고 다른 프로그래머는 그렇지 않습니다. 프로젝트 시작시 제공되는 지침은 첫 번째 프로그래머 그룹에 도움이되므로 전반적인 작업이 쉬워집니다. 창의성, 적합성이 결여 된 것을 (창의적으로) 구성하는 두 번째 그룹에게는 거의 도움이되지 않을 수 있습니다.


1

프로젝트의 규모와 많은 사람들이 작업하고 있다고 생각합니다. 숙련 된 프로그래머는 서로 다른 형식의 스타일을보고 두 가지 모두에서 무슨 일이 있었는지 알 수 있지만 일관성이 있어야 눈을 쉽게 잡을 수 있습니다. 컬 괄호가없는 한 줄 ifstatments를 수행하려는 경우 해당 프로젝트를 사용해서는 안됩니다. 나는 분명하게 잘리는 것을 좋아하고 내가 얻을 수있는 매우 컴팩트합니다. 통계가 있으면 한 줄을 만들면 다음과 같이 보입니다.

if() {}
else() {}

또는:

if() {} else () {}

그러나 한 줄이면 mulitiline의 간격을 사용해서는 안됩니다. 그것은 내가 일하는 방법입니다. 나는 객체가 호출되는 방식을 신경 쓰지 않으며 그것이 호출 된 횟수에 달려 있습니다. 그것의 몇 번 호출되면 오히려 오히려 객체를 시작하고 그것이 구성 요소가 있는지 여부와 그렇지 않은지에 달려 있습니다. 생성자가 있고 호출하는 경우 :

Object.method();
Object.method2();

그런 다음 객체를 완전히 인스턴스화하여 피할 수 있었을 때 객체 구성자 메소드를 두 번 호출했습니다.

foreach 및 for 루프와 관련하여 lanauge에 대해서도 일부 lanauge는 foreach 루프의 배열을 볼 때 더 나은 제어 기능을 제공하므로 temp 배열의 키와 값을 갖습니다. 그리고 나는 어떤 라그나 게 (lague)들이 어떤 종류의 최적화를 가지고 있다는 것을 알고 있습니다. 왜냐하면 그들은 루프를보고 그것이 호출 될 횟수를 정확히 알 수 있기 때문입니다.


1

첫 번째 예제는 훌륭하지 않지만 (수정 중에 버그가 발생하기 쉽다는 주장은 약간의 무게를 가짐) 일반적으로 실제로 선호 하도록 성장했습니다. 개발자가 약간 다른 코딩 스타일을 사용 하도록 .

다른 팀원의 코드로 작업 한 후 때로는 몇 개월 만에 인라인으로 작동하기 시작합니다. git blame . 10 년 이상 회사에 근무한 후에는 500 만 줄의 코드 중 어디에서나 특정 클래스를 작성한 사람을 80 % 이상의 정확도로 말할 수있을 것입니다.

동의하지 않는 스타일을 사용하는 코드를 볼 때 약간의 "램프 시간"이 있지만 그 시간에 실제로하고있는 것은 "오, 이것은 John Doe의 코드처럼 보입니다. 그는 스타일 X를 사용하지만 스타일 Y 등은 사용하지 않습니다. "). 그리고 그것은 맥락의 전체 힙을 가져옵니다. 첫 번째 근사치에 따르면 John의 코드에서 기대할 사항, 즉 그가 이해하는 코드베이스의 다른 부분과 그가 이해하지 못하는 부분, SQL 전문가 또는 GUI 초보자인지 여부를 알 수 있습니다.

포맷터를 통해 모든 사람의 코드를 실행하면 기본적으로이 정보가 제거되어 정보가 숨겨져 git blame실행을 방해하지 않을 수 있습니다.


0

이것은 실제로 조직 유형에 따라 다릅니다.

소규모 슈퍼 히어로 그룹이라면 어떤 유형의 스타일이든 좋습니다. 모든 사람이 고유 한 스타일을 가지고 있고 내부적으로 일관되고 일관성이 있다면 이것이 필요한 모든 과정입니다. 슈퍼 히어로들은 "Jane은 대괄호를 가지고 있으므로 이것이 의미하는 바입니다"또는 "Jack은 변수에 camelCase를 사용합니다"라고 말할 것입니다.

모든 사람을 B + 플레이어로 만드는 데 보편적 인 표준이 가장 좋습니다. 이것에 의해 당신의 슈퍼 히어로가 풀릴 것입니다. 그러나 1 명의 A 플레이어와 24 명의 B 플레이어 및 6 명의 C 플레이어가 B +까지 평균을 내기를 원한다면 일관된 표준을 원합니다. 이 경우, 한 명의 A 플레이어가 가능한 한 빨리 모든 사람의 코드를 훑어 볼 수 있도록 모든 사람이 같은 일을하기를 원합니다.

많은 사람들이 "하지만 잠깐, 왜 B와 C 플레이어들을 멀리하지 않습니까?"

현실은 슈퍼 히어로가 많지 않다는 것입니다. Google에서 광고를 찾아서 양육하는 데 비용이 들지만 Ma Bell에 새로운 청구 시스템을 추가하는 것이 후자의 팀에게는 비용 효과적 일 수 있습니다. (그리고 당신이 정말로 슈퍼 히어로를 가지고 있다면, 그들 중 4 명 또는 5 명은 12 명보다 두 배나 비쌉니다)

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