에서 이 질문 내가 물었다 좋은 코드를 작성에서 나쁜 작가 방해합니다 당신을 존재 여부. "좋은 코드의 의미에 따라 다릅니다"로 시작되는 많은 답변이 있습니다.
"좋은 코드"와 "나쁜 코드"라는 용어는 매우 주관적인 것으로 보입니다. 한 가지 견해가 있기 때문에 다른 사람들의 견해와는 매우 다를 수 있습니다.
"좋은 코드"를 작성한다는 것은 무엇을 의미합니까? "좋은 코드"는 무엇입니까?
답변:
좋은 코더는 좋은 풀 플레이어와 같습니다.
당신은 프로 풀 플레이어를 볼 때 처음에는 감동하지 않을 것입니다. "물론, 그들은 모든 공을 넣었지만 쉽게 촬영할 수있었습니다!" 이것은 수영장 선수가 샷을 할 때 어떤 공이 어떤 포켓에 들어갈 지 생각하지 않고 큐볼 이 어디로 갈지 생각 하기 때문 입니다. 다음 샷을 설정하는 데는 엄청난 기술과 연습이 필요하지만,보기가 쉽다는 것을 의미합니다.
이제이 은유를 코드로 가져 오면 좋은 코더는 쉽고 간단하게 보이는 코드를 작성합니다 . 그의 책에서 Brian Kernighan의 많은 사례가이 패턴을 따릅니다. "속임수" 의 일부는 문제와 그 해결책에 대한 적절한 개념을 제시 합니다. 문제를 충분히 이해하지 못하면 솔루션을 지나치게 복잡하게 만들 가능성이 높아지고 통일 된 아이디어를 얻지 못할 것입니다.
문제의 적절한 개념화를 통해 가독성, 유지 보수성, 효율성 및 정확성과 같은 다른 모든 것을 얻을 수 있습니다. 해결책이 매우 간단 해 보이므로 추가 설명이 필요하지 않기 때문에 주석이 적을 것입니다. 좋은 코더는 제품의 장기적인 비전을보고 그에 따라 개념을 형성 할 수 있습니다.
( 원본 )
편집 : 기본 개념은 "좋은 품질"또는 "좋은시"를 규칙에 넣을 수없는 것과 같은 방식으로 "코드 품질"을 규칙에 넣을 수 없으므로 컴퓨터가 "예, 좋은 예술"이라고 말할 수 있도록하는 것입니다. 또는 "아니요, 나쁜시". 현재 유일한 방법은 코드가 다른 사람에게 얼마나 이해하기 쉬운 지 보는 것입니다.
코드를 얼마나 빨리 이해할 수 있는지 외에는 좋은 기준이 없습니다. 간결함 과 가독성 간의 완벽한 타협점을 찾아 코드를보기 좋게 만듭니다 .
"분당 WTF"(위)는 사실이지만 더 일반적인 규칙의 결과 일뿐입니다. WTF가 많을수록 이해가 느려집니다.
RemoveCustomer방법은 실제로 나사를 조이지 않고 cutomer를 제거한다는 것입니다. 예쁘게 보이도록 몇 시간을 보낼 수 있지만 실제로 작동한다는 의미는 아닙니다. '코드를 얼마나 빨리 이해할 수 있는지'가 '좋은 코드'의 유일한 기준은 아닙니다.
당신은 좋은 코드를 작성할 때 ...
코드가 좋은지 어떻게 측정합니까?
좋은 코드는 예상대로 작동합니다. 필요할 때 좋은 코드를 쉽게 수정할 수 있습니다. 좋은 코드는 재사용을 위해 재사용 될 수 있습니다.
코드
버그 무료
재사용 가능
독립적
덜 복잡한
잘 기록 된
변경하기 쉬운
좋은 코드라고합니다.
좋은 프로그램은 완벽하게 작동하며 버그가 없습니다. 그러나 어떤 내부적 특성이 그러한 완전성을 산출합니까? 그것은 신비가 아닙니다. 우리는 가끔 생각 나게 할 필요가 있습니다. C / C ++, C #, Java, Basic, Perl, COBOL 또는 ASM으로 코딩하든 모든 우수한 프로그래밍은 단순성, 가독성, 모듈성, 계층화, 디자인, 효율성, 우아함 및 선명도 효율성, 우아함과 동일한 시간에 걸쳐 우수한 품질을 나타냅니다. 명확성
출처 : MSDN
익숙한 것 같습니까?
필립스는 새 제품의 디자인을 볼 기회를주었습니다. 개발이 진행됨에 따라 점점 불안 해졌고 우려 사항을 관리자에게 알리기 시작했습니다. 나는 그에게 디자인이 "깨끗하지 않다"고 Dijkstra의 디자인이 아름다운 방식으로 "아름다워야"한다고 반복해서 말했다. 그는 이것이 유용한 의견이라고 생각하지 않았다. 그는 우리가 예술가가 아닌 엔지니어임을 상기시켰다. 그의 마음 속에서 나는 단순히 내 취향을 표현하고 있었고, 그는 판단을 내릴 때 어떤 기준을 사용하고 있는지 알고 싶었습니다. 나는 그에게 말할 수 없었다! 위반 한 원칙에 대해 설명 할 수 없었기 때문에 내 의견은 단순히 무시되었고 작업은 계속되었습니다. 내“맛”을 설명하고 동기를 부여 할 방법이 있어야한다는 것을 감지하고, 좋은 디자인과 나쁜 디자인을 구별 할 수있는 원리를 찾기 시작했습니다. 엔지니어는 매우 실용적입니다. 그들은 아름다움에 감탄하지만 유용성을 추구합니다. “아름다움”이 유용한 이유에 대한 설명을 찾으려고 노력했습니다.
자연어 코드 품질 기준 (최소 복사 / 붙여 넣기, 스파게티 없음 등)을 제외하고는 좋은 산업 코드는 항상 약간 순진하고 너무 장황하게 보입니다.
int key = i;
const bool do_not_create = false;
Record r = cache.get(key, do_not_create);
++i;
반대로
Record r = cache.get(i++, false);
do_not_create = false평균 "통과 false는 AS do_not_create또는"패스가 만들어집니다 그래서 인자 " false는 AS do_create가 생성되지 않도록 인수"? 인수 이름을 사용할 수있는 언어에서는 선호합니다 cache.get (key:i, create: false); i += 1;.
좋은 코드는 사람마다 다르며 함께 일하는 언어도 좋은 코드로 간주되는 것에 영향을 미칩니다. 일반적으로 프로젝트에 접근하면 다음 사항을 찾습니다.
이 모든 것 외에도 응용 프로그램 디자인이 전체적으로 의미가 있습니까? 응용 프로그램에 상주하는 코드는 세계 최고 일 수 있지만 응용 프로그램의 전체 디자인이 이해가되지 않으면 여전히 문제가 될 수 있습니다.
가독성에 친절하게 동의하지 않겠습니다. 아니요, 완벽하지는 않습니다. 좋은 코드를 읽을 수 있어야하며 충분한 주석으로 쉽게 얻을 수 있습니다.
그러나 나는 두 가지 종류의 WTF를 고려합니다. 프로그래머가 프로그래밍 101보다 더 많은 것을 얻었는지 궁금한 것과 코드의 성실성을 절대 이해하지 못하는 것입니다. 일부 코드는 처음에는 매우 이상하게 보일 수 있지만 실제로는 어려운 문제에 대한 매우 독창적 인 솔루션입니다. 두 번째는 WTF 미터에 포함되어서는 안되며 주석으로 피할 수 있습니다.
매우 읽기 쉬운 코드는 매우 느릴 수 있습니다. 덜 읽기 쉬운 솔루션은 속도를 크게 향상시킬 수 있습니다. R은 자주 사용되는 언어의 훌륭한 예입니다. 우리는 가능한 한 for-loops를 피하는 것을 좋아합니다. 일반적으로 읽을 수는 없지만 가장 빠른 코드가 더 나은 코드라고 생각합니다. 즉, 개선이 실제로 진행되지 않고 코드의 기능을 설명하기에 충분한 주석이 삽입됩니다.
또한 많은 과학 응용 프로그램에서 메모리 관리는 매우 중요합니다. 매우 읽기 쉬운 코드는 메모리 사용에있어 부주의 한 경향이 있습니다. 더 많은 객체가 생성됩니다. 경우에 따라 메모리를 똑똑하게 사용하면 코드를 다시 읽을 수 없게됩니다. 그러나 예를 들어 기가 바이트의 DNA 서열을 저글링하면 메모리가 중요한 요소입니다. 다시 한 번, 가독성에 관계없이 메모리를 많이 사용하지 않는 코드가 더 나은 코드라고 생각합니다.
예, 좋은 코드에는 가독성이 중요합니다. 나는 Uwe Liggis의 adagium을 알고 있습니다. 그러나 내 분야 (통계 유전체학)에서 일주일의 계산 시간과 40Gb 이상의 메모리 사용량은 비정상으로 간주되지 않습니다. 따라서 두 배의 속도와 메모리의 절반을 향상시키는 것이 가독성의 추가 비트보다 훨씬 가치가 있습니다.
다른 프로젝트에서 일하는 동료가 와서 각 코드 블록을 넘지 않고 내가하고있는 일을 이해할 수있을 때 좋은 코드를 작성하고 있음을 알고 있습니다. 무엇을하고 있는지 보여줍니다.
그 대신에 "잠깐만 요!" 그는 "오, 알았어. 네가 거기서 뭘했는지 알아."
좋은 코드에는 몰래 해결 방법이나 '해킹'이 많이 없습니다. 당신이 그것을 쓰는 동안, 당신은 또한 스스로에게 "나는 이것이 그것을하는 좋은 방법이 아니라는 것을 알고 있습니다. 그러나 나는 지금이 방법으로해야 할 것입니다. 나는 상기시킬 것입니다. 나중에 개선하기 위해 ... "
