코드를“예쁘게 보이게”하는 데 집착하면 어떤 이점이 있습니까?

때때로 나는 코드를 "예쁘게 보이게"만드는 것보다 어리석은 시간 (시간)을 소비한다. 나는 물건을 대칭 적으로 보이게 만드는 것을 의미합니다. 실제로 전체 클래스를 빠르게 스크롤하여 "예쁘거나 깨끗하지 않은"것으로 보이는 것이 있는지 확인합니다.

나는 시간을 낭비하고 있습니까? 이런 종류의 행동에 가치가 있습니까? 때로는 코드의 기능이나 디자인이 변경되지 않을 수도 있습니다. 코드를 재구성하여 더보기 좋게 만듭니다.

나는 단지 완전히 강박 장애입니까? 아니면 이것에 숨겨진 이점이 있습니까?

자동 포맷터를 사용하십시오. 실제로 수동으로 코드를 편집하는 데 많은 시간을 소비한다면 아무런 이유가 없기 때문에 도전을받지 않고 지루하지 않을 것이라고 생각할 것입니다. VS의 Ctrl + K, Cntrl + D는 전체 문서를 포맷합니다. 좀 더 무거운 것을 원한다면 스타일 경찰과 같은 것을 사용할 수 있습니다.

코드에 자부심을 갖는 것이 좋지만 똑똑한 (가장 효율적인 솔루션을 찾고 있습니다.이 경우 도구를 사용하여 지루한 프로세스를 자동화하고) 일을 끝내는 것 (다른 무엇을 할 수 있는지)은 아닙니다 그 시간 동안 일한 적이 있습니까?).

더 잘 이해할 수 있도록 아무것도 바꾸지 않으면 시간 낭비입니다.

숨겨진 코드는없고, 읽기 쉬운 코드와 유지 관리가 쉽습니다.

거대한 코드베이스가 없다면 "시간"은 약간 과도하게 보입니다. 모든 것이 완벽 할 필요는없고 단지 좋을 필요가 있습니다

판단의 문제입니다. 당신이 시간을 보내고 있다면, 나는 당신이 정상을 넘어 가고 있다고 말할 것입니다. 그러나 자동 포맷터로는 할 수없는 일과 회사 코딩 표준에서 포착하기 어려운 코드를 더 읽기 쉽게하기 위해 할 수있는 일이 있습니다.

예를 들어 클래스에서 변수를 선언 할 때 논리 그룹화를 선호합니다. 논리를 쉽게 따라갈 수 있습니다.

코드는 일반적으로 "한 번 작성하고 많이 읽음"으로 간주되므로 독서 경험을 즐겁게 만드는 것은 좋은 습관입니다. 그러나 제 생각에는 레이아웃은 명확한 명명 규칙, 깨끗한 추상화 및 체계적인 메소드 서명보다 훨씬 중요합니다.

기본 사고 과정에 결함이 있기 때문에 심각한 WTF 순간을 일으키는 아름다운 형식의 코드를 보았습니다. 몇 시간을 소비한다면 레이아웃보다는 디자인 및 리팩토링에 소비합니다 ....

아니 당신은 완전히 OCD되지 않습니다. 프로그래머로서 내가들은 가장 큰 칭찬은 "여러분의 코드는 너무 깨끗해서 내 동생이 알아낼 수있었습니다."였습니다.

언젠가 누군가 당신의 코드를 지원해야 할 것입니다. 깨끗한 코드는 지원하기가 훨씬 쉽습니다. 그리고 언젠가는 너일지도 모른다. 6 개월 또는 1 년 후에는 자신이 한 일을 기억하지 못할 것입니다. 그러나 깨끗하고 읽기 쉬운 경우 빨리 돌아옵니다.

그것은 코드가 쓰레기라면 꽤 쓰레기가되는 데 도움이되지 않는다고 말했습니다. 그러나 잘 구성되어 있고 기능적인 문제가있는 경우 기능을 개선하기가 훨씬 쉬울 것입니다.

아니오 - 코드 모양을 만드는 예쁜에 집착하고 요점 .

내가 찾은 몇 가지 지혜는 다음과 같습니다.

왜 코드가 깔끔해야하는지 물어보십시오 .

pretty의 정의에 따라 시간을 낭비하거나 낭비하지 않을 수 있습니다.

포맷팅의 기본 정리 (The Fundamental Theorem of Formatting)는 좋은 시각적 레이아웃이 프로그램의 논리적 구조를 보여준다고 말합니다. 코드를 예쁘게 보이게하는 것은 가치가 있지만 코드 구조를 보여주는 것보다 가치가 없습니다. [pg 732, 코드 컴플리트 2 판, Steve McConnell]

동시 버전 시스템 을 사용 하여 코드 변경 사항을 추적하는 경우 -동일한 커밋 내에서 코드 형식 변경 사항과 논리적 / 추가 기능 변경 사항을 혼합하지 마십시오.

변경 사항을 찾기가 더 어려워지고 다른 팀 구성원이 파일을 편집하는 경우 불필요한 병합 충돌이 발생할 수 있습니다. 형식을 변경해야하는 경우 다른 팀 구성원이 해당 파일에서 작업하고 있지 않은지 확인하십시오. [파라 그래스, Pg 93, Subversion을 사용한 실용적인 버전 관리, 2 판]

또한 Martin Fowler는 하루 종일 '두 개의 모자를 쓰고'서로 전환하는 것에 대해 이야기합니다. 기능 추가 용 모자 하나, 리팩토링 용 모자 하나.

1. 새로운 기능 추가를 고려합니다 (Feature Hat)
2. 기존 코드를 잘 읽고 이해하면서 깔끔하게 정리하십시오. (리팩토링 모자)
3. 변경 사항을 커밋하십시오.
4. 기능을 추가하십시오. (피처 모자) 등등 ....

[낙서 pg 57ish, 리팩토링, 마틴 파울러]

따라서 전체 코드베이스를 확인하는 데 몇 시간을 소비하지 마십시오. 다음 기능을 추가하기 위해 필요한 코드를 충분히 확인하십시오.

간단히 말해서 ... 각 코드는 처음 도착했을 때보 다 더 좋은 상태로 두십시오.

순수한 형식이라면 코드를 어떻게 형식화하고 싶은지 예쁜 프린터를 가르치는 데 시간을 투자하는 것이 좋습니다. 다소 선행 비용이 들지만, 타이머를 2-3 번 사용하는 것이 좋습니다.

실제 리팩토링이라면 아닐 수도 있습니다. 개념적으로 깨끗한 코드는 앞으로 더 쉽게 수정하고 "항상 깨끗하게"하는 것이 다른 냄새 나는 코드가 있기 때문에 무언가를 통과하려는 유혹을 줄입니다.

약간 도움이되지만 많은 시간을 할애 할 가치는 없습니다. 또한 개선 사항에 변수 범위, RAII, 그룹 복사 / 붙여 넣은 코드 등을 추가해야합니다.이 모든 작업을 수행하면 1 년 정도 지나면 코드의 기능을 이해해야 할 때 1000 배 더 쉬워집니다.

깨끗한 코드를 만들어야하지만 몇 시간이 걸리지 않습니다.

C의 경우 gnu- 프로그램 gnu-indent gnu-indent가 있는데, 일식에는 Java 용 코드 포맷터가 적어도 있으며 다른 언어에도 사용할 수있는 도구가 있다고 생각합니다. 짧은 스위치 케이스 문에서와 같이 특정 목적으로 규칙을 위반하려는 경우 파일을 올바르게 들여 쓰기 위해 몇 번의 클릭만으로 몇 분이 소요됩니다.

 switch (foo) {
      case a:  foo (a);             break; 
      case b:  foob ();             break;
      case c:  /* intent. empty */
      case d:  foocd ();            break; 
      default: allPrettyAligned (); break; 
 }

지정하기 어렵다.

무언가를 감추어 깨끗해 보인다고 생각되면 자동화 할 수있는 피상적 인 것에 집중하고있는 것입니다.

"잘못된 코드 작성 오류"에 대한이 고전 기사를 읽고 사람들이 일반적으로 들여 쓰기 (자동으로 수행 할 수 있음)가 왜 사소한 것이라고 생각하는지 정확하게 알 수 있습니다.

http://www.joelonsoftware.com/articles/Wrong.html

특히이 목록은 다음과 같습니다.

좋아, 지금까지 프로그래머로서 세 가지 수준의 성취에 대해 언급했다.

1 . 당신은 부정한 것을 깨끗하게 알지 못합니다.

2. 코딩 규칙을 준수하는 수준에서 청결에 대한 피상적 인 아이디어가 있습니다.

삼 . 표면 아래의 불결한 미묘한 냄새가 나기 시작하여 코드를 작성하고 수정하기에 충분합니다.

그래도 더 높은 수준이 있습니다.

4. 부정한 코를 사용하면 코드가 더 정확 해 지도록 의도적으로 코드를 설계 할 수 있습니다.

이것은 실제 기술입니다. 문자 그대로 화면에 오류를 표시하는 규칙을 발명하여 강력한 코드를 작성합니다.

"시간"? 글쎄, 당신의 대답은 "또는"이 아니라 "그리고"라고 말하고 싶습니다. 예, 당신은 강박 장애가 있지만 그에 대한 이점이 있습니다.

아마.

코드를보다 쉽게 ​​읽을 수있게합니까? 탈지하기 쉽고, 어디서 멈추고 시작하는지 파악하고, 함수, 변수 등을 찾는 것이 더 쉬워 집니까? 코드가 더 명확하게 작동합니까? 구성 프로세스로 인해 일부 설계 결정을 다시 검토하고 궁극적으로 포기한 데드 코드 또는 스트립 아웃 반 베이크 솔루션을 제거해야합니까? 그렇다면 절대 가치가 있습니다.

반면에, 코드를 실제로 다루기 쉽게 만들지 않고 자신의 미적 감각에 어필하는 어리석은 방법을 알아 냈다면 시간 낭비입니다.

나에 관해서는, 나는 이것의 OCD 끝에 빠지는 경향이 있지만 멈추지 않을 것입니다. 클래스 또는 함수에 대한 문서를 제공하는 행위로 인해 실제로 어떻게 작동하는지 생각해야합니다. 나를 모르는 누군가가 그것을 이해할 수 있도록 작성하고 있습니다. 그리고 코드가 작동하는 방식에 대해 경고와 경고 및 사과를 많이한다면, 그것이 끝났다고 선언하기 전에 한 번 더 조정할 필요가 있다는 매우 강력한 경고입니다.

코드를 예쁘게 보이게 만드는 데있어 첫 번째 문제는 결국 코드 생성 및 프리젠 테이션 / 포맷을 자랑스럽게 생각하기 때문입니다.

그러나 동료 또는 미래 개발자를 위해 코드를 과도하게 형식화하지 않도록주의해야합니다. 당신에게 예쁘지 않을 수도 있습니다. :)

문제 (강제적 행동)와 증상 (강박 적으로 형식화)을 인식합니다.

원인과 치료는 어떻습니까?

• 너무 많은 시간을 일하고 있습니까?
• 당신은 좌절, 지루, 불안합니까?
• 다음 과제는 무엇입니까? 원하지 않는 것입니까?
• 마지막 휴가는 언제입니까? 승진? 성취에 대한 인식?
• 소각 관련 문제입니까?
• 당신은 죽음의 행진에 있습니까?

때때로 이러한 증상은 대담한 변화를 일으키거나 나아가 야 할 때입니다.

Yourdon 's 책은 그 제목이 작음에도 불구하고 많은 도움이되는 제안을 가지고 있으며 많은 조직에 매우 사실적인 설명을하고 있습니다.

http://dev.co.ua/docs/Edward%20Yourdon%20-%20Death%20March.pdf

당신은 꽤 통찰력이 있고 나는 당신이 답을 알고 있다고 생각합니다.

이제 스스로 행동 할 권한을 부여하십시오.

이런 소!
당신은 들여 쓰기에 대해 들어 본 적이 있습니까?

20 년 이상 사용되어 온 코드 포맷 유틸리티입니다. 메가 버킷 옵션이있어 원하는대로 코드를 자동으로 포맷 할 수 있습니다.

ermm-그러나 C에서만 작동하지만 일부 C ++에서는 작동하지 않습니다 ... (wtf? GNU가 왜 업그레이드하지 않습니까?)