코드를 볼 때 어떤 것이 즉시 알람 벨을 울립니 까? [닫은]

몇 주 전에 저는 소프트웨어 장인 행사에 참석했으며 한 의견은 "우리가 볼 때 나쁜 코드를 모두 알아볼 것"이라고 말했으며 모두가 더 이상의 논의없이 현혹하게 고개를 끄덕였습니다.

모든 사람들이 자신이 평균 이상의 드라이버라고 생각하는 진실이 있기 때문에 이런 종류의 일은 항상 나를 걱정합니다. 나는 나쁜 코드를 인식 할 수 있다고 생각하지만 다른 사람들이 코드 냄새로 간주하는 것에 대해 사람들의 블로그와 소수의 책에서만 자세히 설명하지 않기 때문에 더 배우고 싶습니다. 특히 한 언어에서는 냄새가 나지만 다른 언어에서는 냄새가 나는 것을 듣는 것이 흥미로울 것 같습니다.

쉬운 것부터 시작하겠습니다.

주석 처리 된 코드의 비율이 높은 소스 제어의 코드 -왜 존재합니까? 삭제 되었습니까? 반 완성 된 작품인가요? 아마도 주석 처리되어서는 안되며 누군가가 무언가를 테스트 할 때만 수행 되었습니까? 개인적으로 나는 이런 종류의 것이 여기저기서 이상한 라인 일지라도 실제로 성가신 것을 알지만, 큰 코드가 나머지 코드와 산재되어 있으면 완전히 받아 들일 수 없습니다. 또한 일반적으로 나머지 코드의 품질이 모호 할 수 있음을 나타냅니다.

/* Fuck this error */

일반적으로 넌센스 try..catch블록 내부에서 발견되며 내 관심을 끌기 쉽습니다. 뿐만 아니라 /* Not sure what this does, but removing it breaks the build */.

몇 가지 더 :

• 여러 개의 중첩 된 복잡한 if명령문
• 정기적으로 논리 흐름을 결정하는 데 사용되는 try-catch 블록
• 일반적인 이름과 기능 process, data, change, rework,modify
• 100 줄의 6 가지 또는 7 가지 다른 브레이스 스타일

방금 찾은 것 :

/* Stupid database */
$conn = null;
while(!$conn) {
    $conn = mysql_connect("localhost", "root", "[pass removed]");
}
/* Finally! */
echo("Connected successfully.");

MySQL 연결을 무차별하게 수행하는 것이 올바른 방법입니다. 데이터베이스에 연결 수에 문제가있어 시간이 초과되지 않았습니다. 이를 디버깅하는 대신 작동 할 때까지 반복해서 시도했습니다.

저에게있어 주요 위험 신호는 중복 된 코드 블록입니다. 이는 프로그래밍 기초를 이해하지 못했거나 기존 코드베이스를 적절히 변경하기에는 너무 무서웠 ​​음을 보여주기 때문입니다.

나는 또한 의견이 부족한 적을 붉은 깃발로 생각했지만 최근에는 의견이없는 아주 좋은 코드를 많이 사용하여 다시 완화했습니다.

실제 가치가 없다는 사실에도 불구하고 프로그래머가 얼마나 영리한지 보여 주려고 시도하는 코드 :

x ^= y ^= x ^= y;

• 20,000 (과장) 라인 기능. 두 개 이상의 화면을 차지하는 모든 기능에는 리팩토링이 필요합니다.

• 같은 줄을 따라 계속 진행되는 클래스 파일. 원래 클래스의 목적과 기능을 명확하게하는 클래스로 추상화 할 수있는 몇 가지 개념이있을 수 있습니다.

• 비 설명 적, 사소하지 않은 변수 또는 너무 많은 사소한 비 설명 적 변수 이것들은 실제로 일어나는 수수께끼를 추론합니다.

{ Let it Leak, people have good enough computers to cope these days }

더 나쁜 것은 상용 라이브러리에서 나온 것입니다!

너무 자세한 주석은 영어 컴파일러가 있으면 컴파일하고 완벽하게 실행하지만 코드에서 설명하지 않는 것은 설명하지 않습니다.

//Copy the value of y to temp.
temp = y;
//Copy the value of x to y.
y = x;
//Copy the value of temp to x.
x = temp;

또한 제거 할 수있는 코드에 대한 주석에는 코드가 몇 가지 기본 지침을 준수했습니다.

//Set the age of the user to 13.
a = 13;

컴파일 할 때 경고를 생성하는 코드.

설명적인 이름 대신 이름에 숫자가있는 함수는 다음과 같습니다.

void doSomething()
{
}

void doSomething2()
{
}

기능 이름을 의미로 만드십시오! doSomething 및 doSomething2가 유사한 작업을 수행하는 경우 차이점을 구별하는 함수 이름을 사용하십시오. doSomething2가 doSomething의 기능을 분리 한 경우 해당 기능의 이름을 지정하십시오.

매직 넘버 또는 매직 스트링.

   if (accountBalance>200) { sendInvoice(...); }

   salesPrice *= 0.9;   //apply discount    

   if (invoiceStatus=="Overdue") { reportToCreditAgency(); }

• 아마도 최악이 아니지만 구현 수준을 분명히 보여줍니다.

  if(something == true) 

• 언어에 for 루프 또는 반복자 구성이있는 경우 while 루프를 사용하면 구현 자의 언어 이해 수준을 보여줍니다.

  count = 0; 
  while(count < items.size()){
     do stuff
     count ++; 
  }
  
  for(i = 0; i < items.size(); i++){
    do stuff 
  }
  //Sure this is not terrible but use the language the way it was meant to be used.

• 문서 / 주석의 철자 / 문법이 코드 자체만큼이나 많이 사용됩니다. 그 이유는 코드는 사람이 읽고 기계를 실행하기위한 것이기 때문입니다. 이것이 우리가 고급 언어를 사용하는 이유입니다. 문서가 잘 나오지 않으면 코드베이스를 보지 않고 선입관 적으로 부정적인 의견을 만들 수 있습니다.

내가 즉시 눈에 띄는 것은 깊게 중첩 된 코드 블록 의 빈도입니다 (if, while 등). 코드가 자주 2 ~ 3 레벨 이상 깊어지면 디자인 / 논리 문제의 징조입니다. 그리고 8 개의 둥지처럼 깊어지면 부서지지 않는 좋은 이유가 더 낫습니다.

학생의 프로그램을 채점 할 때 때때로 "깜박임"스타일로 말할 수 있습니다. 이것들은 즉각적인 단서입니다.

• 열악하거나 일관성이없는 형식
• 행에 두 개 이상의 빈 줄
• 비표준 또는 불일치 명명 규칙
• 반복되는 코드 일수록 반복되는 단어가 많을수록 경고가 강해집니다.
• 간단한 코드 조각은 지나치게 복잡합니다 (예 : main에 전달 된 인수를 복잡한 방식으로 확인)

내 첫인상이 드물지 않으며,이 경고음 이 시간의 약 95 %에 해당합니다 . 한 가지 예외로, 언어를 처음 접하는 학생은 다른 프로그래밍 언어의 스타일을 사용하고있었습니다. 다른 언어의 관용구에서 자신의 스타일을 파고 다시 읽으면 알람 벨이 제거되어 학생은 완전히 학점을 얻었습니다. 그러나 그러한 예외는 드 rare니다.

더 고급 코드를 고려할 때 다음은 다른 경고입니다.

• 의 존재는 많은 데이터 만 보유 할 "구조체"있는 자바 클래스. 필드가 공개 또는 개인인지 여부와 상관없이 게터 / 세터를 사용하더라도 여전히 잘 설계된 디자인의 일부는 아닙니다.
• 네임 스페이스와 같이 이름이 좋지 않고 코드에 실제로 응집력이없는 클래스
• 코드에서 사용되지 않는 디자인 패턴에 대한 참조
• 설명없이 빈 예외 처리기
• Eclipse에서 코드를 가져 오면 수백 개의 노란색 "경고"가 코드에 표시됩니다. 대부분 사용되지 않은 가져 오기 또는 변수로 인해

스타일면에서 나는 일반적으로보고 싶지 않습니다.

• 코드 만 에코하는 Javadoc 주석

이것들은 나쁜 코드의 단서 일뿐 입니다. 프로그래머의 의도를 모르기 때문에 잘못된 코드처럼 보일 수도있는 것은 아닐 수도 있습니다. 예를 들어, 무언가가 지나치게 복잡해 보이는 좋은 이유가있을 수 있습니다. 다른 고려 사항이있을 수 있습니다.

개인적으로 좋아하는 / 애완 동물 친구 : IDE 생성 이름이 커밋됩니다. TextBox1이 시스템에서 중요하고 중요한 변수라면 코드 검토에 또 다른 문제가 있습니다.

변수 에 사용 된 변수 이름과 유사한 이름이있는 경우 완전히 사용하지 않는 변수 .

많은 사람들이 언급했습니다 :

//TODO: [something not implemented]

나는 물건이 구현되기를 원하지만 적어도 그들은 메모를했다. 내가 더 나쁜 생각은 :

//TODO: [something that is already implemented]

Todo는 귀찮게 제거하지 않으면 무가치하고 혼란 스럽습니다!

모든 것을 읽으려면 아래로 스크롤 해야하는 방법입니다.

메소드 이름의 연결 :

public void addEmployeeAndUpdatePayrate(...) 


public int getSalaryOrHourlyPay(int Employee) ....

설명 :이 경고음이 울리는 이유는이 방법이 단일 책임 원칙을 위반할 가능성이 있음을 나타냅니다 .

분명히 GPL의 소스 코드를 상업용 비공개 소스 프로그램에 연결합니다.

즉각적인 법적 문제를 야기 할뿐만 아니라 제 경험상 일반적으로 코드의 다른 부분에도 반영된 부주의 또는 무관심을 나타냅니다.

언어에 구애받지 않음 :

• TODO: not implemented
• int function(...) { return -1; } ( "구현되지 않음"과 동일)
• 예외가 아닌 이유로 예외가 발생합니다.
• 오용 또는 일치하지 않는 사용 0, -1또는 null같은 뛰어난 반환 값.
• 왜 실패해서는 안되는지 설득력있는 설명이없는 주장.

언어 별 (C ++) :

• 소문자로 된 C ++ 매크로.
• 정적 또는 글로벌 C ++ 변수
• 초기화되지 않거나 사용되지 않은 변수.
• 모든 array new분명히 RAII 안전하지입니다.
• 분명히 경계 안전하지 않은 배열이나 포인터 사용. 이 포함됩니다 printf.
• 초기화되지 않은 배열 부분 사용

Microsoft C ++ 전용 :

• Microsoft SDK 헤더 파일에서 이미 정의한 매크로와 충돌하는 식별자 이름
• 일반적으로 Win32 API를 사용하면 큰 알람 벨이 발생합니다. MSDN을 항상 열어 두어야하며, 의심이있을 때마다 인수 / 반환 값 정의를 찾아보십시오. (편집)

C ++ / OOP 특정 :

• 가상 클래스와 가상이 아닌 메소드를 모두 갖는 가상 클래스와 비가 상 메소드를 갖는 구현 (콘크리트 클래스) 상속.

기괴한 들여 쓰기 스타일.

매우 인기있는 스타일이 몇 가지 있으며 사람들은 그 토론을 무덤으로 가져갈 것입니다. 그러나 때때로 나는 누군가가 정말로 드물거나 심지어 집에서 자란 들여 쓰기 스타일을 사용하는 것을 본다. 이것은 아마도 자신 이외의 다른 사람과 코딩하지 않았 음을 나타냅니다.

열거 형이나 전역 적으로 정의 된 변수 대신 많은 텍스트 블록을 사용합니다.

안좋다:

if (itemType == "Student") { ... }

보다 나은:

private enum itemTypeEnum {
  Student,
  Teacher
}
if (itemType == itemTypeEnum.Student.ToString()) { ... }

베스트:

private itemTypeEnum itemType;
...
if (itemType == itemTypeEnum.Student) { ... }

약한 유형의 매개 변수 또는 메소드의 값을 리턴합니다.

public DataTable GetEmployees() {...}

public DateTime getHireDate(DataTable EmployeeInfo) {...}

public void FireEmployee(Object EmployeeObjectOrEmployeeID) {...}

• 여러 삼항 연산자는 함께 중독, 그래서 대신 닮은의 if...else블록을, 그것은된다 if...else if...[...]...else블록
• 밑줄이나 camelCasing이없는 긴 변수 이름. 내가 뽑은 일부 코드의 예 :$lesseeloginaccountservice
• 주석이 거의 없거나 전혀없는 파일에 수백 줄의 코드가 있고 코드가 명확하지 않은 경우
• 지나치게 복잡한 if진술. 코드의 예 : if (!($lessee_obj instanceof Lessee && $lessee_obj != NULL))나는 아래로 뛰어 들었다 .if ($lessee_obj == null)

코드 냄새 : 모범 사례를 따르지 않음

모든 사람들이 자신이 평균 이상의 드라이버라고 생각하는 진실이 있기 때문에 이런 종류의 일은 항상 나를 걱정합니다.

전 세계 인구의 50 %가 평균 지능보다 낮습니다. 좋아, 그래서 어떤 사람들은 정확히 평균적인 지능을 가지 겠지만 까다 롭지 않게합시다. 또한, 어리 석음의 부작용 중 하나는 자신의 어리 석음을 인식 할 수 없다는 것입니다! 이 문장들을 결합하면 상황이 좋지 않습니다.

코드를 볼 때 어떤 것이 즉시 알람 벨을 울립니 까?

많은 좋은 것들이 언급되어 왔으며, 일반적으로 모범 사례 를 따르지 않는 것이 코드 냄새 인 것 같습니다 .

모범 사례는 일반적으로 무작위로 발명되지 않으며 종종 이유가 있습니다. 여러 번 주관적 일 수 있지만, 내 경험상 그들은 대부분 정당화됩니다. 모범 사례를 따르는 것이 문제가되지 않아야하며, 왜 그런지 궁금해하는 경우 무시하거나 불만을 제기하지 말고 조사하십시오. 아마도 정당화 될 수도 있고 아닐 수도 있습니다.

모범 사례의 한 예는 한 줄만 포함하더라도 모든 if-block에 curly를 사용하는 것입니다.

if (something) {
    // whatever
}

당신은 그것이 필요하다고 생각하지 않을 수도 있지만, 최근 에 그것이 버그의 주요 원인이라는 것을 읽었습니다 . 항상 대괄호 사용에 대해서도 Stack Overflow 에서 논의되었으며 if 문에 대괄호가 있는지 확인하는 것도 Java의 정적 코드 분석기 인 PMD 의 규칙 입니다 .

"최상의 방법이므로" "이러한 이유는 무엇입니까?"라는 질문에 대한 대답은 결코 아닙니다. 왜 모범 사례가 무엇인지 설명 할 수 없다면, 모범 사례가 아니라 미신입니다.

"Froz 하위 시스템의 설계가 완전히 중단 되었기 때문"이라고 설명합니다.

그것은 전체 단락에 걸쳐 진행됩니다.

다음과 같은 리 팩터가 발생해야한다고 설명합니다.

그러나 그것을하지 않았다.

그들은 시간이나 역량 문제로 인해 당시 상사에 의해 그것을 바꿀 수 없다고 들었을 수도 있지만, 아마도 사람들이 사소한 것일 수도 있습니다.

감독자가 j.random이라고 생각하면 프로그래머가 리팩토링을 수행 할 수 없으면 감독자가이를 수행해야합니다.

어쨌든 이런 일이 발생하면 코드가 전력 정책과 함께 분할 된 팀에 의해 작성되었으며 보크 서브 시스템 설계를 리팩터링하지 않았다는 것을 알고 있습니다.

실화. 당신에게 일어날 수 있습니다.

누구나 코드가 절대 경로로 파일을 합법적으로 참조 해야하는 예를 생각할 수 있습니까?

일반적인 예외 잡기 :

try {

 ...

} catch {
}

또는

try {

 ...

} catch (Exception ex) {
}

지역 남용

일반적으로 너무 많은 지역을 사용하면 수업이 너무 크다는 것을 알 수 있습니다. 이 코드를 자세히 조사해야한다는 경고 플래그입니다.

생성하려는 추상화에 대한 이해가 부족한 클래스 명명 규칙. 또는 그것은 추상화를 전혀 정의하지 않습니다.

첫 번째 파일 Data에서 제목 이 30,000 줄 이상인 VB 클래스에서 극단적 인 예가 떠 오릅니다 . 적어도 6 개의 다른 파일로 분할 된 부분 클래스였습니다. 대부분의 메소드는 이름이 같은 저장된 proc를 래퍼로 사용했습니다 .FindXByYWithZ()

덜 극적인 예를 들더라도, 나는 우리가 논리를 완전히 구식이 아닌 클래스에 '덤핑'하여 완전히 일반적인 제목을 부여하고 나중에 후회했다고 확신합니다.

언어의 기본 기능을 다시 구현하는 기능. 예를 들어, 문자열의 ".length"속성을 호출하는 대신 JavaScript에서 "getStringLength ()"메서드가 표시되면 문제가있는 것입니다.

#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...

물론 문서의 종류 및 가끔 중첩없이 #define의