나중에 다시 돌아와서 작업할 수 있도록 코드에 플래그를 어떻게 지정합니까?

StackOverflow https://stackoverflow.com/questions/335378

  •  22-07-2019
  •  | 
  •  

문제

C#에서는 #warning 그리고 #error 지시문,

#warning This is dirty code...
#error Fix this before everything explodes!

이런 식으로 컴파일러는 내가 아직 해야 할 일이 있다는 것을 알려줄 것입니다.코드를 잊어버리지 않도록 표시하기 위해 어떤 기술을 사용합니까?

도움이 되었습니까?

해결책

그것들을 표시하십시오 // TODO, // HACK 또는 Visual Studio의 작업 창에 표시되는 다른 주석 토큰.

보다 작업 목록 사용.

다른 팁

댓글도 할 수 있습니다.

또한 특별한 키워드 Nocheckin을 추가했으며 소스 제어 시스템에 Commit-Hook (최소한 CVS 또는 SVN을 사용하여 매우 쉽게 수행 할 수 있음)를 추가하여 모든 파일을 스캔하고 파일을 찾으면 파일을 확인하지 않습니다. 텍스트는 어디서나 nocheckin입니다.

이것은 무언가를 테스트하고 실수가 체크인되지 않는지 확인하는 경우에 매우 유용합니다 (소스 제어를 위해 노력하는 모든 것의 감시에주의를 기울여야합니다).

나는 조합을 사용합니다 //TODO: //HACK: 그리고 throw new NotImplementedException(); 수행되지 않은 작업을 나타내는 내 방법에. 또한 불완전한 라인에 Visual Studio에 북마크를 추가합니다.

// TODO : 사람의 이름 -이 문제를 해결하십시오.

이것은 Java에 있습니다. 그런 다음이 태그에 대한 모든 참조를 찾을 수있는 일식의 작업을보고 다른 사람에게 할당을 할당하거나 자신만의 만 볼 수 있도록 사람별로 그룹화 할 수 있습니다.

'Do Do'의견은 이론적으로 훌륭하지만 실제로는 적어도 내 경험에서는 그렇게 좋지 않습니다. 당신이 그들을 필요로 할 정도로 오랫동안 멀어지게되면, 그들은 잊혀지는 경향이 있습니다.

나는 Jon T의 일반적인 전략을 선호하지만 보통 코드를 일시적으로 깨뜨려서 고의적으로 정의되지 않은 메소드 참조를 삽입하고 컴파일러가 다시 돌아와야 할 사항에 대해 상기시켜줍니다.

PutTheUpdateCodeHere();

변화의 중간에 모든 것을 떨어 뜨려야한다면 

#error finish this

나중에해야 할 일이라면 버그 추적기로 들어갑니다 (모든 작업에 사용됨).

장애인 상태에서 테스트를 추가하십시오. 그들은 모든 빌드 보고서에 나타납니다.

그래도 작동하지 않으면 버그를 제출합니다.

특히, 나는 의미있는 방식으로 수량이 감소하는 Todo 의견을 보지 못했습니다. 댓글을 썼을 때 할 시간이 없다면 나중에 시간이 걸리는 이유를 모르겠습니다.

내가 정말로 좋아하는 접근법은 Oren Eini가 보여준 것처럼 "해킹 폭탄 테러"입니다. 여기.

try
{
   //do stuff
   return true;
}
catch // no idea how to prevent an exception here at the moment, this make it work for now...
{
  if (DateTime.Today > new DateTime(2007, 2, 7))
    throw new InvalidOperationException("fix me already!! no catching exceptions like this!");
  return false;
}

//TODO: Finish this

vs를 사용하는 경우 도구> 옵션> 환경> 작업 목록에서 자신의 작업 태그를 설정할 수 있습니다.

GVIM은 "// xxx"와 "// todo"를 노란색으로 강조합니다. 이는 처음으로 코드를 다시 표시하여 다시 생각할 때 놀랐습니다.

나는 // todo : or // hack : 이유를 설명하는 메모로 무언가가 완성 된 것을 상기시켜줍니다. 나는 종종 ( '드물게'읽는다) 시간 제약으로 인해 돌아가서 그 것들을 마무리한다. 그러나 코드를 살펴보면 완료되지 않은 내용과 더 중요한 이유에 대한 기록이 있습니다.

하루 종일 또는 일주일에 자주 사용하는 한 가지 의견이 있습니다.

// Chris에서 시작합니다

^^^^^^^^^^^^^^^^^^^^^ 월요일 아침에 부트 스트랩 시간을 최소화 할 수 있도록 어디에서 꺼져 있는지 알려줍니다.

완벽한 세상이 아니며, 우리는 항상 코드를 리팩터링하거나 숙고 할 무한한 시간이있는 것은 아닙니다.

나는 때때로 넣습니다 //REVIEW 코드에서 나중에 돌아오고 싶은 것이 있다면. IE 코드는 작동하지만 아마도 그것이 가장 좋은 방법이라고 확신하지는 않을 것입니다.

// REVIEW - RP - Is this the best way to achieve x? Could we use algorithm y?

동일합니다 //REFACTOR

// REFACTOR - should pull this method up and remove near-dupe code in XYZ.cs

의견을 제시합니다.

// TODO: <explanation>

아직 구현하지 못했고 잊어버리고 싶지 않은 일이라면요.

// FIXME: <explanation>

내가 옳지 않다고 생각하는 일이고 나중에 다시 찾아오거나 다른 사람의 눈으로 살펴보고 싶은 경우.

#error/#warning 옵션은 생각해본 적이 없습니다.그것들도 유용할 수 있습니다.

깨진 코드에는 // fixme : xxx를 사용하고 // chgme : xxx는주의를 기울여야하지만 작동하는 코드 (아마도 제한된 컨텍스트에서만)를 사용합니다.

이것들은 제가 해결해야 할 일을 플래그하는 데 도움이 된 세 가지 방법입니다.

  1. 검사 해야하는 코드 옆에 주석 플래그를 배치하십시오. 대부분의 컴파일러는 공통 플래그를 인식하고 조직화 된 방식으로 표시 할 수 있습니다. 일반적으로 IDE에는이 깃발을 위해 특별히 설계된 시계 창이 있습니다. 가장 일반적인 주석 플래그는 다음과 같습니다. // 사용 방법 : //

    // TODO : 릴리스되기 전에이 문제를 해결하십시오. 아직 생성되지 않은 메모리를 사용하기 때문에 액세스 위반이 발생합니다.

  2. 릴리스 전에 해결해야 할 무언가를 표시하는 한 가지 방법은 쓸모없는 변수를 만드는 것입니다. 사용되지 않은 변수가있는 경우 대부분의 컴파일러는 경고합니다. 이 기술을 사용할 수있는 방법은 다음과 같습니다.

    int this_is_an_access_violation = 0;

  3. IDE 북마크. 대부분의 제품은 향후 참조를 위해 북마크를 코드에 배치 할 수있는 방법이 있습니다. 이것은 당신만을 볼 수 있다는 점을 제외하고는 좋은 생각입니다. 코드를 공유하면 대부분의 IDE는 북마크를 공유하지 않습니다. IDE의 도움말 파일 시스템을 확인하여 북마크 기능을 사용하는 방법을 확인할 수 있습니다.

일부라면 장기 기술 부채, 당신은 다음과 같은 의견을 말할 수 있습니다.

// TODO: This code loan causes an annual interest rate of 7.5% developer/hour. Upfront fee as stated by the current implementation. This contract is subject of prior authorization from the DCB (Developer's Code Bank), and tariff may change without warning.

... 오류. 당신이 단순히 무시하지 않는 한, 할 일이 그렇게 할 것이라고 생각합니다.

저는 C ++ 프로그래머이지만 내 기술이 C# 또는 그 문제에 대한 다른 언어로 쉽게 구현 될 수 있다고 생각합니다.

나는있다 ToDo(msg) 생성자가 로그 메시지를 출력하는 로컬 범위에서 정적 객체를 구성하는 매크로. 이렇게하면 미완성 된 코드를 처음 실행할 때 로그 출력에 대해 알림을받습니다.

다음과 같이 보입니다.

class ToDo_helper
{
  public:
     ToDo_helper(const std::string& msg, const char* file, int line)
     {
       std::string header(79, '*');
       Log(LOG_WARNING) << header << '\n'
                        << "  TO DO:\n"
                        << "    Task:  " << msg << '\n'
                        << "    File:  " << file << '\n'
                        << "    Line:  " << line << '\n'
                        << header;
     }
};

#define TODO_HELPER_2(X, file, line) \
  static Error::ToDo_helper tdh##line(X, file, line)

#define TODO_HELPER_1(X, file, line) TODO_HELPER_2(X, file, line)
#define ToDo(X) TODO_HELPER_1(X, __FILE__, __LINE__)

... 그리고 당신은 다음과 같이 사용합니다.

 void some_unfinished_business() {
   ToDo("Take care of unfinished business");
 }

나는 또한 todo : 댓글을 사용합니다. 나는 그들이 실제로 해결되지 않는다는 비판을 이해하고 버그로보고 된 것이 더 좋을 것이라는 비판을 이해합니다. 그러나 나는 그것이 몇 가지 점을 놓친다고 생각합니다.

  • 나는 끊임없이 리팩토링하고 물건을 재 설계 할 때 무거운 개발 중에 가장 많이 사용합니다. 그래서 나는 항상 그들을보고 있습니다. 그런 상황에서는 대부분의 사람들이 실제로 해결됩니다. 또한 Todo를 검색하기가 쉽습니다. 내가 아무것도 놓치지 않았는지 확인합니다.

  • 코드를 읽는 사람들, 당신이 잘 쓰여지거나 해킹 당했다고 생각하는 지점을 아는 것이 매우 도움이 될 수 있습니다. 익숙하지 않은 코드를 읽고 있다면 조직 패턴, 이름 지정 규칙, 일관된 논리 등을 찾는 경향이 있습니다. 편의를 위해 일관성을 한두 번 위반해야한다면 그 효과에 대한 메모를 보겠습니다. 그렇게하면 아무것도없는 논리를 찾는 데 시간을 낭비하지 않습니다.

대부분의 프로그래머가 여기에서하는 것처럼 보이면, 나는 todo 댓글을 사용합니다. 또한 Eclipse의 작업 인터페이스를 사용합니다 Mylyn. 작업이 활성화되면 Mylyn은 내가 열린 모든 리소스를 기억합니다. 이렇게하면 추적 할 수 있습니다

  1. 파일에서 무언가를 해야하는 곳 (그리고 무엇),
  2. 내가해야 할 파일, 그리고
  3. 그들이 어떤 과제에 관련되어 있는지.

"TODO :"의견을 제외하고, 많은 IDE는 "작업 :"댓글을 벗어난 열쇠입니다. 일부 IDE는 자신의 특수 식별자를 구성 할 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top