2009-12-02 4 views
8

일부 프로그래머는 결국 아무 것도 유용하지 않은 코드를 추가합니다. 예를 들어 (C 번호) :쓸모없는 코드를 사용하는 것이 허용됩니까?

[Serializable] 
class Foo { 
    // ... 
    string SerializeMe() { 
     return new XmlSerializer(typeof(this)).Serialize(this).ToString(); // serialize to xml (syntax wrong, not important here) 
    } 
} 

클래스는 Serializable로 표시되어 있지만, 직렬화 유일한 방법은 모든 클래스 속성을 필요로하지 않습니다 XmlSerialization의 수단입니다.

필자는 개인적으로 이런 종류의 쓸데없는 코드를 싫어하지만 필자는이 코드를 자주 보며 다른 사람들이 생각하는 것에 대해 궁금해. 이것은 결국 심각한 결점이 아닌가? 업계에서 일반적인 관행입니까? 아니면 이건 평범한 것이고 무엇이든지 상관없이 제거해야합니까?

답변

4

추가 코드 (쓸모없고 추가 한 코드)를 읽는 데 최소한의 노력 만 들었습니까?

예 (그렇다고 생각합니다.)라면 코드에 없어야합니다. 이런 코드는 유용하지 않은 여분의 스 니펫으로 오염되어 있습니다.
"나중에 리팩터링"은 실제로 사용했는지 기억할 6 개월 후, 고통 스러울 수 있습니다.

0

쓸데없는 의미는 사용 할 수없고 사용하지 않을 것이라고 생각합니다. 나는 또한 열린 문이 아주 열려 있다고 생각합니다.

+0

(!) 참고 : 코드는 항상 쓸모없는, 주석, 또는 기능이없는 탓;) – Ropstah

+1

나는 아내와 논쟁하는 것처럼 쓸모없는 일들을 항상 할 수 있고 .... –

+0

이것은 당신이나 그녀가 당신이나 둘 다 중독되어있는 호르몬을 생산하기 때문에 쓸모가 없습니다. – Ropstah

1

상용 프로젝트에서 나는 그렇지 않다고 말하고 싶습니다. 특히 누군가가 독서를 위해 그것을 분해하고 나서 WTF의 순간을 가질 수 있다면 말입니다.

가정용 프로젝트에서 - 왜 안되는 지, 나중에 사용하기 위해 일부 발췌문을 보관합니다.

+1

-1 스 니펫 플러그인이나 소스 컨트롤에 스 니펫을 보관하는 것이 좋습니다. –

+1

개인 프로젝트가 아닌 다른 사람이 원하는대로 할 수 있습니다. –

+0

어느 쪽이든 소스 컨트롤을 사용해야하고 확실히 체크 인되어 있지 않아야합니다.;) –

1

글쎄,이 특정 코드는 배경을 알지 못하면 주석 처리 할 수 ​​없지만 실제로 필요하지 않으면 코드에 아무 것도 포함하지 않는 규칙을 엄격히 따르고 있습니다. 또는 적어도 언젠가 내가 이미 마음에두고있는 어떤 것을 위해 언젠가는 유용 할 것임을 아십시오.

10

나의 경험칙

사용하지 않을 경우 제거하십시오.

모든 과잉 의견, 특성은 단지 잡음 일 뿐이며 코드를 읽을 수 없게 만드는 데 도움이됩니다. 거기에 남아있는 경우 코드 기반에서 더 많은 잉여 코드를 권장합니다. 그래서 그것을 제거하십시오.

18

좋은 소스 제어는 더 이상 필요없는 쓸데없는 코드 또는 코드를 제거해야 함을 의미합니다. 나중에 언제든지 소스 컨트롤에서 검색 할 수 있습니다.

+0

동의합니다. 그것은 또한 내 견해입니다. 또한 변경된 내용을 볼 수 있기 때문에 같은 파일의 이전 버전을 비교할 때도 도움이됩니다! 예를 들어 "xxx 버전 이후로 직렬화에 대한 지원이 중단되었습니다"라고 말할 수 있습니다. 그래서 암묵적인 문서를 추가합니다. –

5

나는 YAGNI 원칙을 따르려고하기 때문에이 또한 저를 괴롭힌다.

1

이것은 잘못된 코드입니다.

잘못된 코드는 일반적인 습관입니다.

가끔씩 "깨지지 않는"내용을 변경하려는 노력은 가치가 없습니다.

+0

전 완전히 동의하지 않습니다. 버그는 '신성한 코드'를 만지려는 두려움 때문에 수십 년 동안 소스 코드에 고정되어있는 태도와 같습니다. 내가 좋아하는 소설을 찍어 낙서를 그 위에 넣으면 어떨까요? 그 소설을 더 이상 읽고 싶습니까? –

1

더 이상 추가 할 수없는 경우가 아니라 더 이상 제거 할 수 없을 때 완벽하게 달성 된 것으로 보입니다.— 앙투안 드 생 텍쥐페리는

+0

훌륭한 어린이 책을 저술 한 항공기 디자이너 Antoine de Saint-Exupéry의 견적서 수정. "완벽"과 같은 것은 ....이 아닙니다. –

+1

축하해. 코딩 시간이 3 배로 늘어 났고, 당신에게 커미션을 준 사람은 분노를 느낀다. – Graviton

+0

Civilization IV (Leonard Nimoy) 덕분에 원래 견적서가 프랑스어로 번역되었음을 알 수 있습니다. 더 이상 추가 할 수 없을 때가 아니라 더 이상 제거 할 수 없을 때 완벽 함이 달성 된 것으로 보입니다. - Antoine de Saint-Exupery (1900-1944) – Dolphin

4

정말 그것을 좋아하지 않아.

나는 왜 그곳에 있는지 알아 내려고 애 쓰고 있기 때문에 귀중한 시간을 보냅니다. 그곳에 있다면 이유가 있습니다. 이유를 알지 못한다면 코드를 망치기 전에 내가 알아야 할 중요한 것을 놓치고있는 가능성이 있습니다. 이유가 무엇인지, 코드의 일부가 무엇인지, 그저 돌아가서 제거하기에는 너무 게으른 일부 개발자가 방금 떠났던 것을 이해하려고 노력하는 데 시간을 낭비했다는 것을 알게되면 나를 자극합니다.

0

다음에 보관합니다.

을 당신이 그것을 사용하지 않을 것입니다 알고, 또는 그 계획 6 개월 전 관련되는 정지하는 경우, 다음을 당겨 경우이 추가 기능을 사용하려면 활성 계획이 있다면. 먼저 주석을 달고 나중에 완전히 제거하십시오.

공개 된 많은 변수를 다시 조사하는 중이지만 실제로는 보호되거나 개인적으로 필요한 변수 일뿐입니다. 단순히 API 관점에서 노출 될 가능성이 없기 때문입니다. 그들.

2

쓸데없는 한 줄짜리 코드는 제거 할 수 있고 제거해야합니다.

쓰는 데 시간이 걸리는 쓸데없는 코드는 제거 할 수 있어야하고 제거해야합니다 ...하지만 담당 책임자는 이에 대해 기분을 상하게하는 경향이 있습니다. 아마도 가장 좋은 해결책은 ProbablyUselessButWhoKnows 프로젝트를 모든 사람이 2 ~ 3 년 후에 다시 사용할 수있는 무의미한 코드로 체크인 할 수있게하는 것입니다. 다른 방법이 없다면, 사람들은 그것을 삭제하는 것에 대해 긴장할 필요가 없습니다.

(예, 이론적으로는 소스 제어에서 그것을 얻을 수 있지만 소스 제어에서 오래된 삭제 코드가 정확히 매우 검색 할 수 없습니다.)

관련 문제