ProgramingTip

나중에 다시 다시 작업 할 수 있도록 코드에 플래그를 지정하는 방법은 무엇입니까?

bestdevel 2020. 11. 29. 12:05
반응형

나중에 다시 다시 작업 할 수 있도록 코드에 플래그를 지정하는 방법은 무엇입니까?


C #에서는 #warning#error지시문을 사용합니다 .

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

이렇게하면 컴파일러는 내가 아직해야 할 일이 있음을 알려야합니다. 코드를 표시하는 데 사용하는 기술은 무엇입니까?


그들을 마크 // TODO, // HACK또는 비주얼 스튜디오의 작업 창에 표시됩니다 다른 주석 토큰 .

작업 목록 사용을 참조하십시오 .


Todo 댓글도 있습니다.

또한 특별한 키워드 NOCHECKIN을 추가했습니다. 소스 제어 시스템에 커밋 후크를 추가했습니다 (적어도 cvs 또는 svn으로 매우 쉽게 수행 할 수 있음). 모든 파일을 스캔하고 파일이 발견되면 체크인을 거부합니다. 어디에서나 NOCHECKIN 텍스트.

(소스 제어에 커밋 된 모든 것을 비교하는 동안 조심스러운 눈을 통과 함).


수행되지 않은 작업을 표시하기 위해 //TODO: //HACK:throw new NotImplementedException();내 방법 의 조합을 사용합니다 . 또한 Visual Studio에서 불완전한 줄에 책갈피를 추가합니다.


// TODO : 사람의 이름-수정 해주세요.

이것은 Java로되어 있고,이 태그에 대한 모든 참조를 사용할 수있는 작업을 Eclipse에서 볼 수 있고 다른 사람에게 TODO를 할당하거나 자신의 것을 볼 수있는 사람별로 그룹화 할 수 있습니다.


'해야 할 일 일'코멘트는 이론적으로는 훌륭하지만 내 경험 말할 것도 없습니다. 당신이 원하는 필요로 할만 큼 충분히 오랫동안 쫓겨날 것이라면 잊혀지는 경향이 있습니다.

나는 Jon T의 일반적인 전략을 선호하지만, 보통 일시적으로 코드를 깨는 방식으로 수행합니다. 저는 종종 의도적으로 정의되지 않은 메소드 참조를 삽입하고 컴파일러가 돌아갈 필요가있는 것을 상기시켜줍니다.

PutTheUpdateCodeHere();

변경된 모든 것을 삭제해야한다면

#error finish this

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


중단 된 상태에서 테스트를 추가합니다. 모든 빌드 보고서에 표시됩니다.

그래도 작동하지 버그를 신고합니다.

특히 TODO 댓글의 양이 의미있는 방식으로 감소하는 것을 본 적이 없습니다. 댓글을 쓸 때 할 시간이 없었다면 왜 나중에 시간이 있었는지 모르겠습니다.


제가 정말 좋아했던 접근 방식은 Oren Eini가 여기에서 보여준 것처럼 "Hack Bombing" 입니다.

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 : 또는 // HACK :을 사용하여 이유를 설명하는 메모와 함께 즉각적인 사건 발생 알림. 나는 종종 ( '드물게'읽는다) 시간들을 제약으로 돌아가서 그 일 마 발생합니다. 그러나 코드를 완료 할 때 완료되지 않은 부분과 더 중요한 기록이 있습니다.

하루나 주말에 자주 사용하는 댓글이 하나 더 있습니다.

// 여기에서 시작 CHRIS

^^^^^^^^^^^^^^^^^^^^ 월요일 아침에 부트 시간을 최소화 할 수 있습니다 중단 된 부분을 알려줍니다.


저는 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");
 }

완벽한 세상은 코드를 리팩토링하거나 숙고 할 시간이 항상 무한한 것도 아닙니다.

//REVIEW나중에 다시보고 싶은 경우 코드를 입력 합니다. 즉, 코드가 작동하지 않는 것이 최선의 방법이라고 할 수 있습니다.

// 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 사용 방법 :

    // 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.

... 오류. 나는 당신이 단순히 무시하지 않는 한 TODO가 그것을 할 것이라고 생각합니다.


TODO : 주석도 사용합니다. 나는 그들이 실제로 거의 고쳐지지 않는다는 비판을 이해하고 버그로보고하는 것이 더 나을 것이라는 비판을 이해합니다. 그러나 나는 그것이 몇 가지 요점을 놓친다고 생각합니다.

  • 나는 끊임없이 리팩토링하고 재 설계 할 때 과중한 개발 중에 가장 많이 사용합니다. 그래서 나는 항상 그들을보고 있습니다. 그런 상황에서 대부분은 실제로 해결됩니다. 또한 TODO를 검색하는 것도 쉽습니다 : 내가 놓친 것이 없는지 확인하기 위해.

  • 코드를 읽는 사람들이 잘못 작성되었거나 함께 해킹되었다고 생각되는 부분을 아는 것은 매우 유용 할 수 있습니다. 익숙하지 않은 코드를 읽는 경우 조직 패턴, 명명 규칙, 일관된 논리 등을 찾는 경향이 있습니다. 편의를 위해 일관성을 한두 번 위반해야한다면 그 효과에 대한 메모를보고 싶습니다. 그렇게하면 논리가없는 곳에서 시간을 낭비하지 않습니다.


대부분의 프로그래머가 여기서하는 것처럼 저는 TODO 주석을 사용합니다. 또한 Eclipse의 작업 인터페이스 Mylyn을 사용 합니다. 작업이 활성화되면 Mylyn은 내가 열어 본 모든 리소스를 기억합니다. 이 방법으로 추적 할 수 있습니다.

  1. 파일에서 내가 무엇을해야하는지 (그리고 무엇을),
  2. 내가해야하는 파일, 그리고
  3. 어떤 작업과 관련이 있는지.

"TODO :"주석을 제거하는 것 외에도 많은 IDE에서 "TASK :"주석을 제거합니다. 일부 IDE에서는 고유 한 특수 식별자를 구성 할 수도 있습니다.

참고 URL : https://stackoverflow.com/questions/335378/how-do-you-flag-code-so-that-you-can-come-back-later-and-work-on-it

반응형