당신이 따라야 할 가장 이상한 코딩 표준 규칙은 무엇입니까? [닫은]


173

이 질문을 했을 때 나는 거의 항상 명확한 표준을 얻었습니다. 코딩 표준이 있어야합니다.

당신이 따라야 할 가장 이상한 코딩 표준 규칙은 무엇입니까?

그리고 이상하게도, 나는 가장 재밌거나, 최악이거나, 또는 보통의 홀수를 의미합니다.

각 답변에 어떤 언어, 팀 규모 및 어떤 나쁜 영향을 주 었는지 언급하십시오.


19
이 목록을 통해 갑자기 읽은 후 나는이 강제 표준 쓰레기를 피하기 위해 매우 운이 좋은 직업을 가졌다 고 느낀다!
matt b

다음에 직업에 대해 인터뷰 할 때이 질문을 찾아 "Red Flag. Run!" 역할을합니다 . 지시자. 실제로 표준 안티 패턴 코딩.
스투 톰슨

5
그리고 나는 경력 초기에이를 인정하기가 부끄럽다. 나는 팀에 대한 답변 중 하나를 부과했다. 정말 죄송합니다.
JasonFruit

답변:


434

나는 미워 여러 반환의 사용이 금지 될 때를.


26
이 규칙의 가정은 무엇입니까? 개인적으로 나는 다른 반환을 넣어서 쉽게 읽을 수있는 코드에 대한 코드 검토에 실패했습니다.
마크 베이커

22
반면, 처음에 "if (param == null) return null"과 같은 옵션을 제거하면 코드가 상당히 정리되어 다소 범죄적일 수 있습니다.
빌 K

39
해결 방법 : if (! Initialize ()) {RetVal = ERR_BADINIT; Goto ReturnPoint; } (더 많은 코드를 나타냄) ReturnPoint : return RetVal; } 문제 해결됨! ;)
Marc Bernier

9
최근까지 여러 번의 수익이 금지되었습니다. 그런 다음 이것이 C에서 남은 사실이며 C ++ RAII에 의해 더 이상 사용되지 않고 크기가 15 줄 미만인 함수가 밝혀졌습니다. 그 이후로 Braveheart처럼 : "FREEDOM !!!!" ...
:-p

122
선택 : 여러 반환 또는 더 중첩 된 if 문. 여러 번 반품하겠습니다.
랜스 피셔

333

들여 쓰기 예를 들면 다음과 같습니다.

    for(int i = 0; i < 10; i++)
        {
myFunc();
        }

과:

    if(something)
        {
// do A
        }
    else
        {
// do B
    }

152
오 마이 갓 ... 그 사람을 생각 해낸 소시 오 패스를 만날 수 있을까? 그는 저에게 장난에 대해 한두 가지를 가르쳐 줄 수있었습니다.
John Rudy

23
사실이 아닐 수도 있습니다.
Dane

191
들여 쓰기를 되돌릴 때마다 하나님은 유지 보수 개발자를 죽입니다.
Chris Vest

14
농담 해?
Andrea Ambu

21
소중한 바이트를 절약 ... 귀중한, 많이 사용
Spikolynn

326

어쩌면 당신이 얻을 수있는 가장 엉뚱한 것은 아니지만 'tbl'로 데이터베이스 테이블 이름을 시작해야 할 때 정말 싫어합니다.


5
이것이 DB의 헝가리 표기법이 아닙니까?
ARKBAN

19
변수 접두어를 var로 사용하지 않습니까?
Brian R. Bondy

26
비슷한 맥락에서, 데이터베이스의 ID 열에 제품 테이블과 같이 테이블 이름이 접두사로 붙일 때 싫어합니다. productid 열이 있습니다. 때때로 ORM 없이도 스크립팅이 필요 이상으로 두통을 일으키는 중복성
Andrew Ingram

30
실제로 ID 열 앞에 테이블 이름을 추가하는 것이 좋습니다. 쿼리 작성이 조금 더 쉽습니다. 외래 키의 경우 외래 키 필드를 키 필드와 동일하게 만들 수 있습니다.
Craig

38
비슷한 참고로, 테이블 이름이 단수이어야 할 때 나는 그것을 싫어합니다. 내 본능은 "고객"이 아닌 "고객"을 포함하는 테이블의 이름을 지정하는 것입니다. "[Transaction]"대신 테이블의 이름을 "Transactions"로 지정할 수있는 경우 저장해야 할 모든 문제를 인식 할 때까지 사소하게 들립니다.
Atario

248

거의 모든 종류의 헝가리 표기법.

헝가리 표기법의 문제점은 종종 잘못 이해된다는 것입니다. 원래의 아이디어는 의미를 명확하게하기 위해 변수를 접두어로 사용하는 것이 었습니다. 예를 들면 다음과 같습니다.

int appCount = 0; // Number of apples.
int pearCount = 0; // Number of pears.

그러나 대부분의 사람들은이 유형을 사용하여 유형을 결정합니다.

int iAppleCount = 0; // Number of apples.
int iPearCount = 0;  // Number of pears.

두 숫자가 모두 정수이지만 모두가 알고 있지만 사과와 배를 비교할 수 없기 때문에 혼란 스럽습니다.


71
방법에 대한이 조엘 소프트웨어에 대한 포스트를 참조하십시오 적절한 버그를 줄일 수 헝가리어 표기법을 사용 : joelonsoftware.com/articles/Wrong.html을
flicken

9
물론 C 대신 C ++를 사용하면 사과를 배와 비교할 때 컴파일러에서 오류가 발생하도록 코드를 작성할 수 있습니다.
Andreas Magnusson

5
그렇습니다. Joel은 올바르게했습니다. Joel의 버전을 적용하기 위해 컴파일러를 만들 수 있기를 바랍니다.
Loren Pechtel

9
"int cntApples = 0; int cntPeas = 0;"이 아니어야합니까? 즉. 접두사는 변수 "kind"입니다.
Blorgbeard는

42
적어도 첫 번째는 정확합니다 ... "Apple"이있는 모든 것은 앞에 "i"가 있어야합니다. ;)
Johannes Charra 2009

240

현재 근무하는 곳에서는 삼항 연산자를 사용할 수 없습니다.

int value = (a < b) ? a : b;

... 모든 사람이 그것을 "얻지는"않기 때문입니다. "구조가 너무 복잡해지면 다시 작성해야했기 때문에 사용하지 마십시오"라고 말한 경우 (필수 삼항 연산자, 누구?), 이해합니다. 그러나 일부 개발자가 이해하지 못한다고 말할 때 ... 음 ... 물론입니다.


235
모두가 당신의 상사는 자신을 의미합니다.
Brian R. Bondy

13
나는이 캠프에 빠졌지 만 ... 그곳에서 자랐고 조건부 연산자를 사랑하는 법을 배웠습니다 (적절한 경우).
John Rudy

22
어떤 경우 규칙은 : 순수한 아름다움 연산자 "항상 삼항 연산자 사용"해야
바비 잭

16
나는 그것을 좋아하지만, 내가 가장 자주 사용하지 않는 이유는 당신의 경험 "사람들이 그것을 이해하지 못할 것"과 같습니다. 저의 주장은 그들이 개념을 이해할 수 없다면 작동하지 않아야한다는 것입니다 ...
Aidos

7
완전히 새로운 함수를 쓰지 않고 상수 변수를 조건부로 초기화하는 방법은 무엇입니까 (가독성에별로 좋지는 않습니다). 로컬 "변수"에 const를 사용하면 삼항 연산자를 금지하는 것보다 코드를 이해하고 따르는 데 훨씬 좋습니다.
Andreas Magnusson

239

변경시 코드를 제거하지 마십시오. 우리는 모든 변화에 대해 언급하라는 말을 들었습니다. 소스 컨트롤을 사용한다는 것을 명심하십시오. 이 정책은 개발자가 정책에 대해 격분하고 코드를 읽을 수 없게 만드는 방법 때문에 오래 가지 못했습니다.


3
난 정말 싫어 ... 여기에 그렇게하는 사람들이 몇 명 있습니다 (표준이 아닙니다)
chills42

7
그런 규칙 때문에 다른 사람들로부터 물려받은 소스 코드를 인쇄해야한다고 생각합니다. 한 페이지에서, 그것은 회사에 그리 좋지는 않지만 인쇄해야 할 경우 읽을 수있는 유일한 방법입니다. (우리는이 규칙을 따르는 많은 것을 물려 받았다 ...)
John Rudy

3
규칙이 사전 소스 제어를 개발 한 것 같습니다. 또는 프로그래머가 일주일에 한 번만 체크인하기 때문입니다.
Craig

6
이 답변을 읽는 것이 내 일을 100 배 더 좋아 보이게 만드는 것을 좋아합니다.
rjh 2016 년

2
당신을 위해 기분 ... 우리는 4+ 년 동안 SVN에있어,하지만 수석 개발자는 고장 코드에 대한 complanining 앞으로 3 일을 보내고, 그 약에 한번 두달 검사를 미워 : /
빅토르 Svub

204

나는 한때 마이티 VB 왕 의 폭정하에 일했다 .

VB 왕은 MS Excel 및 VBA뿐만 아니라, 데이터베이스 (의 순수한 마스터이었다 개발자들이 컴파일러와 함께 일을하면서 그는 Excel에서 연주 및 데이터베이스에 그에게 도전하는 것은 당신의 경력에 해로운 영향을 미칠 수 ... : 따라서 자신의 성 (姓) ).

물론 그의 엄청난 기술은 개발 문제와 프로젝트 관리 솔루션에 대한 독창적 인 비전을 제공했습니다. VB King 은 엄격한 의미에서 표준을 정확하게 코딩하지는 않지만 정기적으로 그가 시도한 "코딩 표준"및 "모범 사례"에 대한 새로운 아이디어를 얻었습니다 . 종종 성공) 우리에게 부과합니다. 예를 들면 다음과 같습니다.

  • 모든 C / C ++ 배열은 0 대신 인덱스 1에서 시작해야합니다. 실제로 배열의 첫 번째 인덱스로 0을 사용하는 것은 더 이상 사용되지 않으며 Visual Basic 6의 통찰력있는 배열 인덱스 관리로 대체되었습니다.

  • 모든 함수는 에러 코드를 반환합니다 : VB6에는 예외가 없습니다. 왜 우리는 그것들을 전혀 필요로합니까? ( 즉, C ++에서 )

  • "모든 함수는 오류 코드를 반환해야합니다"는 의미있는 유형을 반환하는 함수에는 실용적이지 않으므로 모든 함수는 첫 번째 [in / out] 매개 변수로 오류 코드를 가져야합니다.

  • 우리의 모든 코드는 오류 코드를 검사합니다 ( 이로 인해 제가 경력에서 본 VBScript if-indentation의 최악의 경우가 생겼습니다 ... 물론 "else"절이 처리되지 않았기 때문에 실제로 너무 늦게까지 오류가 발견되지 않았습니다 ).

  • 오늘부터 C ++ / COM으로 작업하고 있으므로 모든 DOM 유틸리티 함수를 Visual Basic으로 코딩합니다.

  • ASP 115 오류는 악하다. 이러한 이유로 VBScript / ASP 코드에서 On Error Resume Next를 사용하여 이러한 오류를 방지합니다.

  • XSL-T는 객체 지향 언어입니다. 상속을 사용하여 문제를 해결하십시오 ( 어느 날 놀랍게도 턱이 열렸습니다 ).

  • 예외는 사용되지 않으므로 제거해야합니다. 이러한 이유로 예외 해제가 발생할 경우 소멸자 호출을 요청하는 확인란의 선택을 취소합니다 ( 전문가가 모든 메모리 누수의 원인을 찾는 데 며칠이 걸렸으며 기꺼이 무시했다는 사실을 알았을 때 거의 곤경에 처했습니다. 숨겨진) 옵션을 다시 확인하는 것에 대한 그의 기술 노트, ) 전에 몇 주 전에 보냈습니다 .

  • COM 모듈의 COM 인터페이스에서 모든 예외를 포착하고 조용히 처리하십시오 ( 이 방법으로 충돌하는 대신 모듈이 더 빠른 것처럼 보일 것입니다 ... 반짝이는 것입니다! ... 위에서 설명한 오류 처리를 사용함에 따라, 실제로 무슨 일이 일어나고 있는지 이해하는데 시간이 걸렸습니다 ... 속도와 정확한 결과를 모두 얻을 수는 없습니까? ).

  • 오늘부터 코드베이스는 4 개의 분기로 분할됩니다. 동기화를 관리하고 모든 버그 수정 / 진화를 손으로 통합합니다.

우리의 항의에도 불구하고 C / C ++ 어레이 , VB DOM 유틸리티 기능OOP 언어로서의 XSL-T를 제외한 모든 것이 구현되었습니다. 물론 시간이 지남에 따라 일부는 발견되고, 흠집이 나고 , 부서지고, 버려졌습니다.

물론 VB King 신용도는 결코 그렇게 겪지 않았습니다. 고위 경영진 중 그는 "최고의 총"기술 전문가로 남아있었습니다.

링크를 따라 볼 수 있듯이 재미있는 부작용이 생겼 습니다. 소스 코드에서 가장 좋은 주석은 무엇입니까?


28
다시 : 1 인덱싱. 때때로 당신은 일어 서서 "멍청하고 잘못된 것"과 같은 강한 말을해야합니다. 모래에 선을 그립니다. 자존하는 자아를 잊고 그냥 말하십시오. 나는 거의 모든 다른 가치 프로그래머가 즉시에 고개를 끄덕와 결합을 시작 것이라는 점을 보장 할 수있다.
커크 Strauser에게

31
@ jrista : 내 텍스트의 철자를 언급하지 않으면 다음을 무시하십시오 ... ... ... ... ... ... ... ... ... 내 텍스트를 주석 처리하는 경우 (1) 수정 제안, (2) 철자 수정, 또는 (3) 전 세계의 모든 개발자가 (그와는 거리가 먼) 영어를 모국어로 사용하는 것은 아니라고 생각합니다. 나에게 정확한 번역을 FRENCH로 보내 주시면 더 좋을 것입니다 ... ^ _ ^ ...
paercebal

4
이 사람이 내 상사라면, 잘 작성되고 문서화 된 불만 목록을 가지고 고위 경영진의 모든 구성원에게 직접 가서 해고 당했을 것입니다. -1 공이 자신을 위해 서 있지 않기 때문에 -1.
muusbolla

34
@muusbolla : 누가 우리가 불평하지 않았다고 말했습니까? 2 명 (나를 포함하여)의 대표단이 문제를 설명하기 위해 CEO에게 곧바로 갈 때까지 그것은 확대되었다. 그러나 나는 정의가 지배하는 이상주의 세계와 실제 세계 사이에 차이가 있다는 점을 말씀 드리게되어 유감입니다. 어떤 상사는 "경영이 잘못되어 있지 않더라도 절대 잘못되지 않는다"고 믿고 있으며 그 교리와 모순됩니다. 그 당시부터 유일하게 행복한 기념품은 3 년 전에 사임 한 날이며 그날 이후로 더 행복한 사람입니다. 어쨌든, 사실이라면, 다운 모드 이유는 절름발이입니다. 죄송합니다.
paercebal

7
@paercebal : En générale, c'est correctance écrit, saque que ququeques petits erreurs :«squatch»: ça doit être«squash»; «이 하루»: 엉뚱한«당일»에 문맥 상; «재고 절차»:«재고 절차»; «초크»세크 릿«초크». Aussi, dans les commentaires, vous utilisez ° mentionned», ce qui doit être«언급»Mais vraiment, 그렇습니다 ça ne justifie pas une telle plate. 반대로, 여러 가지 몬테 레즈 (Monouse une Excellente maîtrise de l' anglais); 박멸!
직관

131

80 년대 / 90 년대에 FORTRAN을 사용한 항공기 시뮬레이터 회사에서 근무했습니다. FORTRAN 컴파일러는 변수 이름으로 8 자로 제한되었습니다. 이 회사의 코딩 표준은 헝가리어 표기 스타일 정보를 위해 처음 세 가지를 예약했습니다. 따라서 5 자만으로 의미있는 변수 이름을 작성해야했습니다!


17
사치 : 우리는 단지 6 개의 문자를 가졌다; 패키지 이름은 g로 시작합니다. 내부 기능이 모두 시작되었습니다. 0p와 같은 코드를 가진 워크 스테이션 드라이버가있었습니다 (그래서 gk0p가 시작되었습니다). 나머지 포트란 이름에 대해 두 문자를 남겨 두었습니다. gk0paa, gk0pab, ...
Jonathan Leffler

103
"내가 네 나이 였을 때, 우리는 2 자 밖에 없었고 대소 문자를 구분하지 않았습니다!"
pookleblinky

53
우리는 잠자리에 들기 3 시간 전에 아침 2시에 일어나야했고, 우리 자신의 컴파일러를 작성하고 회사에 일할 특권을 지불했습니다. 변수 이름으로 문자 A 만 허용되었습니다. 그런 다음 상사는 할렐루야 노래 목록에서 코드를 삭제하고 춤을 추었습니다.
David Arno

12
P : "50 가능한 식별자는 사람에 대한 충분한되어야한다"
크리스 조끼

5
오랫동안 우리와 함께 일했던 BASIC 인터프리터는 두 문자로 된 변수 이름을 가졌습니다. 왜 5에 대해 불평합니까?
David Thornley

107

저는 두 회사가 합병 된 곳에서 일했습니다. '주요한'서버는 K & R C로 작성된 주요 서버 (예 : ANSI 이전)를 가지고있었습니다. 그들은 자바 팀 (두 사무실 모두-아마도 총 20 명)이이 형식을 사용하도록 강요했다.이 형식은 "중괄 토론"의 두 가지 기둥을 기쁘게 무시하고 곧장 미쳤다.

if ( x == y ) 
    {
    System.out.println("this is painful");
    x = 0;
    y++;
    }

18
C와 Java를 시각적으로 크게 구분하면 전환이 쉬워 질 것이라고 생각합니다. (+1은 "미쳤습니다.")
Jeffrey L Whitledge

4
Petzold의 오리지널 'Programming Windows'에 사용 된 Whitesmiths 스타일처럼 보입니다. ;)
Bobby Jack

7
나는 이것이 가장 지능적인 버팀대 스타일이라고 생각합니다. 불행히도, 대부분의 사람들은 그것을 사용하지 않습니다. 중괄호가 의미 적 의미를 갖는 경우, 줄 끝에서 붙어서 무시하지 않아야합니다.
Ryan Lundy

7
@ 키라 레사. 동의하지 않습니다 ... 중괄호에 의미 적 의미가 있는지는 모르겠지만 패턴 일치와 공간 감각에 영향을 줄 수 있습니다. IMO,이 버전은 완전히 없어집니다. 예를 들어, 책갈피를 책 바깥쪽으로 찌르고 페이지와 플러시하지 않기를 원합니다.
Michael Easter

6
이것은 실제로 내가 선호하는 스타일이지만 전 세계의 모든 것이 (Visual Studio 특히) 다른 모드로 기본 설정되므로 포기했습니다. 좋아합니까? 중괄호 포함 된 코드의 "부분"입니다. 즉, if에 대한 단일 명령문을 "처럼 보이도록"강제로 예상됩니다.
Atario

104

금지됨 :

while (true) {

허용됨 :

for (;;) {

4
다른 사람들은 이것이 for (;;) {첫 번째 C 관용구 라고 주장했다 .
Robert P

69
내가 현대적이고 새로운 표정의 스마일을 올바르게 이해한다면,이 표준은 가난한 사람들을 과장하여 성명서를 울리게합니다!
Ben Blank

15
이것은 사실상의 규칙입니다. VC6은 while (true)에 대해서는 컴파일러 경고를 발행하지만 for (;;)에 대해서는 경고하지 않습니다. 그렇지 않으면 동등합니다. 그래서 우리는 경고없는 것을 선택합니다.
user9876

22
Bjarne S.는 그의 책에서 "(;;)는 영원히 읽혀 져야한다"고 말했다. C ++ 제작자에게 충분하다면 충분할 것입니다. :-)
Frank Krueger 2016 년

58
내가 작업 한 최초의 C 프로그램에서 누군가가 #define ever ;;;를 추가 했으므로 "for ever {...}"라고 말할 수 있습니다
James Curran

101

내 친구-우리는 그를 CodeMonkey라고 부를 것이다- 년 전에 코볼에서 사내 개발을하는 대학에서 그의 첫 직장을 얻었다 . 그의 첫 번째 프로그램은 ... [shudder!] 중첩 IF 문을 사용했기 때문에 '우리 표준을 준수하지 않는'것으로 거부되었습니다

코딩 표준은 중첩 된 IF 문 사용을 금지했습니다.

이제 CodeMonkey는 부끄러워하지 않았으며 자신의 능력을 확신했기 때문에 모든 사람에게 체인과 통로 아래로이 규칙이 존재하는 이유를 묻습니다. 대부분은 그들이 알지 못한다고 주장하고 일부는 '가독성'에 관한 것들을 구성했으며 마침내 한 사람이 원래 이유를 기억했습니다. 그들이 사용한 첫 번째 COBOL 컴파일러 버전에는 버그가 있었고 중첩 된 IF 문을 올바르게 처리하지 못했습니다.

물론이 컴파일러 버그는 최소한 10 년 동안 수정되었지만 아무도 표준에 도전하지 않았습니다 . [바아!]

CodeMonkey는 표준을 바꾸는 데 성공했습니다 – 결국!


7
Steven, 이것은 원숭이 실험 이야기를 생각 나게한다 : o) freekvermeulen.blogspot.com/2008/08/…
Nick Dandoulakis

5
@ [Nick D] : 예, 저도 요-따라서 코드 명 "CodeMonkey";-)
Steven A. Lowe


이유가 잘못되었을 수도 있지만 중첩 된 ifs를 피하는 것이 좋습니다 -c2.com/cgi/wiki?ArrowAntiPattern
manojlds

97

밑줄이 금지 된 프로젝트에서 일한 적이 있습니다. 그리고 나는 완전히 금지 된 것을 의미합니다. 따라서 AC # winforms 앱에서 새 이벤트 핸들러 (예 : 버튼)를 추가 할 때마다 기본 메소드 이름을 buttonName_Click ()에서 다른 것으로 바꾸어야합니다. 코딩을 작성한 사람의 자아를 만족시키기 위해서입니다. 표준. 오늘까지 나는 그가 겸손한 밑줄에 대해 무엇을했는지 모른다


23
어쩌면 _는 그의 키보드에서 깨졌을 것입니다;)
Roman Plášil

139
buttonNameUnderscoreClick ()
vitule

9
디버깅 에 FILELINE 을 사용하지 못하게하는 불행한 부작용이 있습니다 . 헤더 파일의 #if __cplusplus extern "C" 그리고 stdint.h의 정수 유형. 그리고 size_t.
Steve Jessop

8
좋은 점은 C #이었습니다.
구성자

4
나는 밑줄을 심각하게 권장하지 않는다 (위에 나열된 OP 케이스는 아니지만). 파스칼이나 낙타 케이스가 제대로 작동 할 때 나에게 두지 않는 것이 두 번의 키 입력 (shift + _)입니다.
TGnat

92

완전히 쓸모없는 데이터베이스 명명 규칙. 모든 테이블 이름은 숫자로 시작해야합니다. 숫자는 표에있는 데이터 종류를 나타냅니다.

  • 0 : 모든 곳에서 사용되는 데이터
  • 1 : 특정 모듈에서만 사용되는 데이터
  • 2 : 룩업 테이블
  • 3 : 캘린더, 채팅 및 메일
  • 4 : 로깅

이름의 첫 글자 만 알고 있으면 테이블을 찾기가 어렵습니다. 또한 이것은 MSSQL 데이터베이스이므로 테이블 이름을 대괄호로 묶어야합니다.

-- doesn't work
select * from 0examples;

-- does work
select * from [0examples];

65
죄송합니다. 정말 죄송합니다.
Kirk Strauser

1
와우-좋아. Letters를 사용하는 것이 문제가 아닌 것 같습니다. 그게 좋은 생각은 아니지만 적어도 모든 테이블 이름을 인용 할 필요는 없습니다.
Mark Brittingham 2016 년

마음이 흔들리는 ... 누가 그걸 생각해 냈습니까? dba?
dotjoe 2009

90

우리는 C ++ 프로젝트를하고 있었고 팀장은 파스칼 사람이었습니다.

그래서 우리는 모든 성가신 C 및 C ++ 구문을 재정의하는 코딩 표준 포함 파일을 가지고있었습니다.

#define BEGIN {
#define END }

그러나 더 기다립니다!

#define ENDIF }
#define CASE switch

이 시간이 지나면 기억하기 어렵습니다.

이것은 완벽하게 읽을 수있는 C ++ 코드를 가져 와서 팀장을 제외하고는 읽을 수 없게 만들었습니다.

또한 헝가리어 역 표기법을 사용해야했습니다.

MyClass *class_pt  // pt = pointer to type

UINT32 maxHops_u   // u = uint32

이상하게도 나는 이것처럼 좋아졌다.


22
미래를 위해
유지할 수없는

2
헝가리어 표기법은 옳습니다. 잘못 했어 ... ick. 적절한 형식 시스템이 두 가지를 모두 능가합니다.
Thelema

5
알다시피, 나는 당신과 함께 있다고 생각합니다. 헝가리 사마귀는 그런 식으로 끝날 때 거의 반대하지 않습니다.
TED

haha는 파스칼에서 C ++로 전환했던 시절 (약 16 년 전)로 되돌아갑니다. {를 볼 때마다 {나는 정신적으로 "{는 BEGIN을 의미한다"고 말해야했습니다. 적어도 나를 위해 그것은 단지 내 머리 속에 있었다.
thomasrutter

6
MS VC ++ 지원에서 일할 때 여러 고객이 이와 같이 작성된 재현 코드를 제출하게했습니다. 실제로 C ++임을 알기까지 시간이 걸렸습니다 (#defines는 포함되지 않았습니다).
JBR 윌킨슨

88

전직에서 :

  • "정상"테이블은 T_로 시작합니다
  • "시스템"테이블 (보통 조회)은 TS_로 시작합니다 (다른 사람이 그날 기분이 좋지 않아서 그렇지 않은 경우 제외)
  • 상호 참조 테이블은 TSX_로 시작합니다
  • 모든 필드 이름은 F_로 시작합니다

네 맞습니다. 모든 단일 테이블의 모든 필드. 우리는 그것이 필드라는 것을 알 수 있습니다.


기본 키 필드에 특별한 접두사가 없었습니까 ???
Czimi

2
@Czimi : 나는 그것을 언급하는 것을 잊었다. 모든 테이블에는 기본 키로 사용되는 FI_ID라는 필드가 있습니다.
Jeromy Irvine

31
으악 ...이 악몽을 발명 한 T_guy는 F_gun로 죽이고 TSX_hell로 보내 져야합니다.
Sergey Skoblikov

3
모든 필드와 테이블에 대해 tbl과 fld가있었습니다. 완전히 쓸모없는 ...
구성자

5
@configurator : 모든 필드에 대해 "tbl"이 있고 모든 테이블에 대해 "fld"가 있습니까? :-)))
Timwi

84

정부 직에서 일하는 동안 내 친구가이 규칙에 부딪쳤다. ++ (사전 또는 사후) 사용이 완전히 금지되었습니다. 이유 : 다른 컴파일러가 다르게 해석 할 수 있습니다.


5
글쎄, 그 시점에서 당신은 물론 포기할 수도 있습니다.
Kirk Strauser

90
어떤 사람은 postfix와 prefix의 차이점을 이해하지 못하여 물 렸으며 컴파일러 버그를 주장한 다음 다른 사람들에게 버그를주었습니다.
Bernard

5
실제로 어떤 상황에서는 옳았습니다. 금지는 약간 위에있는 것처럼 보입니다. 예를 들면 다음과 같습니다. a [i] = i ++; 색인화하는 데 사용되기 전에 또는 후에 증가 할 수 있습니다. 언어는 이것을 정의하지 않습니다.
TED

9
그는 옳습니다. 명령문의 다른 곳에서 동일한 변수를 사용하면 작업 순서가 보장되지 않습니다. 그럼에도 불구하고 잠재적으로 모호한 코드를 사용하지는 마십시오.
Loren Pechtel

2
=정의되지 않은 행동을 일으키는 데 사용될 수있을 뿐만 아니라 금지 될 수도 있습니다.
구성자

81

팀의 절반이 4 칸 들여 쓰기를 선호했습니다. 나머지 절반은 2 칸 들여 쓰기를 선호했습니다.

짐작할 수 있듯이, 코딩 표준은 "모두 동일하게 불쾌"하게하기 위해 3 개를 의무화했습니다 (직접 인용).


42
그래서 탭 식별이 너무 좋습니다. 누구나 편집자에서 크기를 변경할 수 있습니다;)
xardias

41
네, 탭 들여 쓰기는 훌륭합니다 ... 실제로 다른 사람의 파일을 열 때까지 공간이 혼합되어 있지 않아야하거나 공간이 혼합되어 있지 않아야하기 때문에 잘못 정렬 된 것을 찾을 수 있습니다. 그런 다음 자동으로 다시 포맷하면 버전 제어 차이가 심해집니다. 어.
Alan Hensel

41
그렇기 때문에 탭을 사용하여 들여 쓰기하고 공백 만 정렬해야하며 트웨인은 절대 만나지 않아야합니다. 파일에서 공백을 변경하려는 경우 특정 체크인에 대해 변경해야합니다.
joh6nn

16
... 그리고 그것은 작동하지 않습니다. : P
Robert P

10
"똑같이 기분을 상하게"하기 위해 ... 나는 그것을 좋아한다. 다음에 들여 쓰기 표준화 전쟁에서 어떻게 든 사랑받을 때 이것을 기억해야합니다.
Michael Burr

74

관리자가 너무 많은 '매직'을 포함한다고 주장하면서 Reflection을 사용할 수 없었습니다.


10
그래, 마술은 유지하기가 어렵습니다.;) LOL.
Rik

19
즉 : 잘못된 이유, 아마도 바로 규칙이다
바비 잭

71
'매직'읽기 성능으로 인해 유지 관리 할 수없는 모호한 악몽 코드를 제거합니다. 그가 맞아.
gbjbaanb

4
그때는 .Net으로 코딩 할 수 없었습니다. 결국 프레임 워크가 실행되는 방식은 많은 부분을 반영하는 것입니다.
NotMe

5
마법사들 과 함께 ! 항상 마법 과 함께 , 우리의 직업을 훔치고, 여자들을 유혹하고, 아이들을 부패시킵니다!
ZJR

71

내가 가진 가장 이상한 것, 그리고 나를 넘어 뜨리는 데 꽤 오랜 시간이 걸렸던 것은 우리 회사의 소유자가 우리의 신제품이 IE 전용 일 것을 요구했을 때였습니다. FireFox에서 작동한다면 문제가 없었지만 IE 일뿐이었습니다.

하나의 작은 결함을 제외하고는 너무 이상하게 들리지 않을 수 있습니다. 모든 소프트웨어는 Linux에서 실행되는 맞춤형 서버 소프트웨어 패키지 용이며 고객이 구매 한 모든 클라이언트 박스는 Linux였습니다. 이 모든 상자에서 Wine을 얻는 방법 (매우 신뢰할 수 없음)을 알아 내려고 IE에서 실행하고 관리자에게 Wine 문제를 디버깅하는 방법을 교육 할 수 있는지 확인하는 것만으로는 불가능했습니다. 소유자의 요청을 충족시킵니다. 문제는 그가 웹 디자인을하고 있었으며 단순히 웹 사이트를 FireFox와 호환되게하는 방법을 몰랐다는 것입니다.

우리 회사가 파산했다는 것을 알면 충격을받지 않을 것입니다.


1
나는 그것이 매우 이상하다고 말한다.
브래드 길버트

14
자본주의를위한 세 가지 건배!
starblue

46
적자 생존을위한 Yay ...이 사람은 자신의 소프트웨어 사업을 운영 할 자격이 없었습니다.
Mark Brittingham 2016 년

10
마지막 문장이 훌륭했습니다. 이런 결정을 내릴 때 어떻게 누군가를 진지하게 받아 들일 수 있습니까?
Mr. Shickadance 2016 년

54

일반 번호 식별자 이름 사용

현재 진행중인 작업에는 두 가지 규칙이 있습니다.

규칙 1 : 데이터베이스 테이블에 새 필드를 만들 때마다 나중에 사용할 수 있도록 추가 예약 필드를 추가해야합니다. 이 예비 필드는 번호가 매겨집니다 (어느 날 어떤 데이터를 보유할지 아무도 모르기 때문에) 다음에 새 필드가 필요할 때 먼저 사용되지 않은 예비 필드를 찾습니다.

따라서 customer.reserve_field_14고객의 전자 메일 주소가 포함됩니다.

언젠가 우리 상사는 예비 테이블을 도입하는 것에 대해 생각 했지만, 다행히도 우리는 그렇게하지 않도록 설득 할 수있었습니다.

규칙 2 : 당사 제품 중 하나가 VB6으로 작성되었으며 VB6에는 다른 식별자 이름의 총 개수에 대한 제한이 있으며 코드가 매우 크기 때문에이 제한에 부딪칩니다. "솔루션"으로서 모든 지역 변수 이름은 다음과 같습니다 :

  • Lvarlong1
  • Lvarlong2
  • Lvarstr1
  • ...

이로 인해 식별자 제한을 효과적으로 피할 수 있지만이 두 규칙을 결합하면 다음과 같은 아름다운 코드가 생성됩니다.

...

If Lvarbool1 Then
  Lvarbool2 = True
End If

If Lvarbool2 Or Lvarstr1 <> Lvarstr5 Then
  db.Execute("DELETE FROM customer WHERE " _ 
      & "reserve_field_12 = '" & Lvarstr1 & "'")
End If

...

오래된 코드 나 다른 사람의 코드를 수정하는 것이 얼마나 어려운지 상상할 수 있습니다.

최신 업데이트 : 이제 개인 회원을 위해 "예약 절차"도 사용하고 있습니다.

Private Sub LSub1(Lvarlong1 As Long, Lvarstr1 As String)
  If Lvarlong1 >= 0 Then 
    Lvarbool1 = LFunc1(Lvarstr1)
  Else
    Lvarbool1 = LFunc6()
  End If
  If Lvarbool1 Then
    LSub4 Lvarstr1
  End If
End Sub

편집 : 이 코드 패턴이 점점 더 대중화되고있는 것 같습니다. 자세한 내용 은 Daily WTF 게시물을 참조하십시오 . 난시 :)


10
농담이 없습니다. 나는 SQL 주입을 모두 제거하고 제거하는 데 영원히 걸렸다. ;-)
Kirk Strauser

그것은 순수한 악입니다. 나는 당신의 상사 / TL이 그의 기회를 기다리는 대군 주라고 확신합니다.
Manuel Ferreria

5
세상에 누가 이런 규칙을 내놓을 까 ??? 가장 중요한 것은 어떻게 팀이 코드를 관리 하는가?
하센

2
그는 모든 필드를 지정할 필요없이 기본적으로 모든 필드를 선택하여 모든 '예약'필드를 얻었을 것이라고 생각했습니다.
Mr. Shickadance

2
) 당신은 당신이 '% S / 이메일 / reserve_field_12 / g'처럼 somegtinh를 컴파일하기 전에 meaningfull 변수 이름을 사용하여 코드를 작성하고 "올바른 사람"로 교체 할 경우, preprosessing 코드를 사용할 수 maibe
주앙 포르텔

53

내 C ++ 시절에 우리는 ==,> =, <=, && 등을 사용할 수 없었습니다.

if (bob EQ 7 AND alice LEQ 10)
{
   // blah
}

이것은 분명히 "조건부 버그의 오래된 우연한 할당"을 다루는 것이었지만 "변수 앞에 상수를 넣는"규칙 있었습니다.

if (NULL EQ ptr); //ok
if (ptr EQ NULL); //not ok

내가 기억 한 가장 간단한 코딩 표준은 "다음 관리자가 당신이 사는 곳을 아는 악의적 인 정신병자처럼 코드를 작성하십시오"라는 것입니다.


1
ROFL .. C로 작성 포트란
로버트 폴슨

나는 여전히 C #에서 null == 변수를 수행합니다. 걱정할 필요는 없지만 스스로 도울 수는 없습니다. 다른 방법으로 보면 긴장감을 느낍니다. 오래된 습관은 열심히 죽습니다.
Troy Howard

정신병자에 관한 마지막 것은 일부 사람들이 거의 즉시 죽임을 당할 것입니다.
Mr. Shickadance

31
악의적 인 정신병자 +1
rcollyer

포럼에 코드를 게시 할 때 연산자가 HTML로 혼동되는 것을 피하기 위해 때때로 LT 및 SHL과 같은 것을 사용합니다.
supercat

45

헝가리어 표기법.


11
글쎄, 나는 페이지의 제어를 위해 H / N을 좋아한다. 내가 찾아야 할 모든 것이 txtFooBar 일 때 IntelliSense 드롭 다운에서 모든 텍스트 상자 컨트롤을 찾는 것이 훨씬 쉽습니다.
cciotti

20
헝가리어 표기법은 사악한 것이 아니며, 올바르게 사용되어야합니다. joelonsoftware.com/articles/Wrong.html
Czimi

1
컨트롤과 관련하여 인정합니다. 그러면 헝가리어 표기법이 도움이 될 수 있습니다. 그러나 일반적으로 헝가리어 표기법은 더 이상 사용되지 않으며 일반적으로 잘못 사용됩니다. 원래 의도에서 벗어났습니다.
vfilby

9
끔찍하게 오용되었습니다. 아니, 아니
Loren Pechtel

2
많은 사람들이 I, IEnumerable, IList로 인터페이스 이름을 시작합니다. .Net 프레임 워크에서 인터페이스는 I로 시작합니다.
tuinstoel

43

나는 어리석은 규칙이 많았지 만 완전히 이상한 것으로 생각하지는 않았습니다.

가장 어리석은 것은 90 년대 초반에 일했던 NASA 일이었습니다. 100 명 이상의 개발자가 참여한 것은 대단한 일이었습니다. 코딩 표준을 작성한 숙련 된 개발자는 모든 소스 파일이 4 개의 문자로 시작해야하고 첫 번째 문자는 파일을 담당하는 그룹을 대표해야한다고 결정했습니다. 이것은 예전의 FORTRAN 77 프로젝트에 좋은 아이디어였습니다.

그러나 이것은 멋진 계층 적 라이브러리 구조를 가진 Ada 프로젝트이므로 전혀 의미가 없습니다. 모든 디렉토리는 같은 문자로 시작하는 파일로 가득 차 있었고, 그 뒤에 3 개의 더 많은 말도 안되는 문자, 밑줄, 그리고 중요한 파일 이름의 일부가 뒤따 랐습니다. 모든 Ada 패키지는이 5 자 사마귀로 시작해야했습니다. 에이다 "사용"절은 해당 소스 파일에 지방이 아니었다 어떤 식별자에 대한 참조 의미 정도로, (정상적인 상황에서 틀림없이 좋은 일이) 중 하나 허용되지 않았다 도를 이 쓸모가 사마귀를 포함하도록했다입니다. 아마도 이것에 대해 반란이 있었을 지 모르지만, 전체 프로젝트는 주니어 프로그래머들이 고용하고 대학 신입 사원들로부터 신입생이었습니다.

전형적인 할당 진술 (Ada에서 이미 장황하다)은 다음과 같이 보입니다.

NABC_The_Package_Name.X := NABC_The_Package_Name.X + 
  CXYZ_Some_Other_Package_Name.Delta_X;

다행히도 그들은 적어도 80 개가 넘는 기둥을 허용 할만큼 깨달았습니다. 그럼에도 불구하고, 시설 사마귀는 모든 소스 파일의 상단에 Ada "이름"을 사용하여 사마귀를 없애는 상용구 코드가 될 정도로 미움을 받았습니다. 가져온 ( "withed") 패키지마다 하나의 이름이 변경되었습니다. 이처럼 :

package Package_Name renames NABC_Package_Name;
package Some_Other_Package_Name renames CXYZ_Some_Other_Package_Name;
--// Repeated in this vein for an average of 10 lines or so

무엇 우리 가운데 더 창조적 인 것은려고하고 걸렸다 사용 acutally 분별 (또는 바보) 패키지 이름을 확인하기 위해 사마귀. (나는 당신이 무엇을 생각하고 있는지 알고 있지만 설명은 허용되지 않았고 당신을 부끄러워하지 않았습니다! 역겨운 일입니다.) 예를 들어, I는이었다 C 코드 그룹 ommon 및 I는 인터페이스와 패키지를 만드는 데 필요한 W orkstation 기. 우리는 워크 스테이션 담당자와의 브레인 스토밍 세션을 마친 후 패키지 이름을 지정하여 둘 다 필요한 사람이 작성하도록 결정했습니다.

with CANT_Interface_Package;
with WONT_Interface_Package;

1
그럼에도 불구하고 NASA는 여전히 킬로미터 또는 마일 단위로 계산할지 여부를 파악할 수 없었습니다 ...
NotMe

16
젠장, 정말 CUN * _ 및 W * NK_ 패키지 명명 규칙을 사용하겠다고 생각했습니다. 죄송합니다. 느리게 타거나 폭발하는 텍스트 뚜렛이 있습니다. 그러나 당신은 훨씬 더 재미있었습니다!
defmeta

41

한곳에서 작업을 시작하고 소스 컨트롤에 코드를 입력하기 시작했을 때 상사가 갑자기 나에게 와서 커밋을 그만두라고 요청했습니다. 그는 소스 컨트롤을 어지럽히 기 때문에 개발자가 하루에 한 번 이상 커밋을하지 않는 것이 좋습니다. 나는 단순히 그를 틈새 ...

나중에 나는 그가 그것에 대해 생각해 낸 이유는 SVN 서버가 누군가가 만드는 각 커밋에 대해 그에게 (그리고 10 명 이상의 임원) 메일을 보내야하기 때문이라는 것을 이해했습니다. 그리고 소스 컨트롤을 어지럽히면서 자신의 편지함을 작성했다고 추측했습니다.


이메일을 강조 표시하고 삭제를 클릭 함
TheLQ

나는 소위 "청춘 체크인"의 팬이 아닙니다 . 변경이 완료되면 간단하게 커밋하십시오. 나는 또한 내일 아침에 다른 코더를 위해 내 코드가 컴파일 가능하고 나머지 프로젝트에서 최소한 실행할 수 있어야한다는 것을 명심하면서 작업 일이 끝날 때 커밋하고 싶습니다.
Jesse C. Slicer

2
두 세계의 장점을 모두 누리십시오-무언가를 잃고 싶지 않을 때마다 현지 지사에 맡기십시오. 커밋을 마스터 할 준비가되면 커밋을 리베이스하고 스쿼시하십시오. (git 용어를 용서하십시오-수은 및 기타 여러 시스템에서도 가능합니다.)
Michael Anderson

위의 모든 내용에 동의합니다. 버전 관리에 접근하는 근본적인 문제입니다. 기술적 인 해결책이 없습니다. git-svn으로 옮기는 것을 고려했는데 로컬 저장소로 작업 한 다음 SVN 저장소로 물건을 푸시 할 수 있었지만 하루의 모든 커밋에 대한 메일을 하나의 거대한 배치로 보냈을 것입니다. 내 상사에게는 아무것도 없습니다.
Avihu Turzion

34

Sql Server 2000의 저장 프로 시저를 통해 모든 데이터베이스 쿼리 수행. 복잡한 다중 테이블 쿼리에서 다음과 같은 간단한 쿼리까지 :

select id, name from people

절차를지지하는 주장은 다음과 같습니다.

  • 공연
  • 보안
  • 유지 보수성

나는 절차 주제가 논란의 여지가 많다는 것을 알고 있습니다.


2
테이블 및 열 이름은 고유하지 않지만 SP 이름은 유지 관리 성을 향상시킬 수 있습니다. 이렇게하면 코드 참조를보다 쉽게 ​​찾을 수 있습니다. 유지 보수성이 더 좋은 다른 장점이 있다면 나는 그것들을 모른다. 보안은 SP를 사용하는 주요 이유입니다.
Jeffrey L Whitledge

2
나는 일반적인 목적으로 100 % wtf가 아니지만 다음 링크를 참조하십시오 : codinghorror.com/blog/archives/000292.html
azkotoki

2
"보안은 SP를 사용하는 주된 이유입니다."아니요. SQL Server의 SP는 더 안전하지 않습니다. 동적 SQL을 사용하여 수행 할 수있는 paremeterized 쿼리로 호출 될 때만 안전합니다.
Flory

4
Nah : sprocs가 유용합니다. 때때로 고통 스러울 수 있지만 더 나은 재사용 가능한 데이터베이스 인터페이스를 작성하게됩니다. dba는 성능 문제를보다 쉽게 ​​분석하고 앱 코드를 변경하지 않고도 프로덕션 시스템을 업데이트 할 수 있습니다. 나는 sprocs에서 biz 로직을 옹호하지 않습니다.
Robert Paulson

4
컴파일 된 코드에 쿼리를 저장하는 것은 매우 고통스러운 일입니다. 저는 추상화만을위한 100 % 프로 시저 정책보다 100 % 늦습니다
annakata

33

1000 줄의 코드 당 165 개의 단위 테스트 (자동화 할 필요는 없음)가 있어야합니다. 그것은 약 8 라인마다 한 번의 테스트로 작동합니다.

말할 것도없이, 일부 코드 줄은 상당히 길며, 함수 는 체인을 허용하기 위해이 포인터를 반환 합니다 .


단위 테스트는 어떻게 자동화되지 않습니까?
pupeno

그들은 마법의 숫자 8을 어떻게 생각해 냈습니까?
Rohit

1
164가 있으면 어떻게됩니까? 166?
Daniel Daranas

8
6 줄과 비슷합니다.
재귀 적

1
그것은 당신의 테스트가 얼마나 세밀하게 결정되었는지에 달려 있습니다. 나는 function(x).should == 2단일 테스트로 간주 하지만 다른 사람들은 10 개를 묶어서 단일 테스트라고 부릅니다.
오리온 에드워즈

30

클래스의 모든 함수를 알파벳순으로 정렬하여 "더 찾기 쉽게"만들었습니다. ide가 드롭 다운되었다는 것을 신경 쓰지 마십시오. 클릭 수가 너무 많았습니다.

동일한 기술 책임자가 소스 코드에서 모든 주석을 제거하는 앱을 작성했습니다.


3
글쎄, 왜냐면 주석은 혼란 스럽기 때문이다. 그리고 컴파일 타임에 프리 프로세서가 얼마나 많은 사이클을 절약 할 수 있을까! (앱은 규칙보다 훨씬 재미 있습니다. 좋은 것입니다.)
ojrac

7
물론이야! 개발자는 :) 시간 쓰기 의견을 낭비하지, 쓰기 코드로되어있다
다니엘 Rikowski을

2
네! 그리고 의견은 빌드를 느리게 만듭니다!
Greg D

2
그럼에도 불구하고 멤버를 유형 (필드, 속성, 메서드) 및 이름별로 정렬하는 것이 좋습니다.
abatishchev

3
헤더와 소스 모두에서 각 그룹 내에서 알파벳순으로 메서드, 멤버 등을 정렬합니다 ...하지만 강박 관념 때문입니다.
Jon Purdy

29

1987 년쯤에 저는 요한 계시록 사용법을 알고있는 소수의 사람들 중 한 명 이었기 때문에 저를 고용 한 회사에서 일을했습니다. 당신이 들어 본 적이 없다면, 계시는 본질적으로 PC 기반의 Pick 운영 체제 구현이었습니다. Pick OS에 대해 많은 것을 말할 수 있습니다. 다수의 초소형 공급 업체 (최소한 Prime 및 MIPS)가 Pick 또는 자체 맞춤형 구현을 사용했습니다.

이 회사는 Prime shop이었으며 사내 시스템에는 정보를 사용했습니다. (아니, 그 이름은 Prime의 Pick 구현이었습니다.) 그들은 PC 기반 시스템을 구축하기 위해 주와 계약을 맺었고, 모든 일을하기 전에 계시 프로젝트에 약 1 년을 투자했습니다. 또한 MIS 책임자 인 그는 더 이상 두 가지 일을 할 수 없다고 결정하고 저를 고용했습니다.

어쨌든, 그는 Prime 기반 소프트웨어에 대해 여러 가지 코딩 표준을 수립했으며, 그 중 다수는 1) 80 열 덤 터미널의 사용과 2) Prime 이후의 사실이라는 두 가지 기본 조건에서 파생되었습니다. 비주얼 에디터가 없어서 직접 작성했습니다. Pick 코드의 마법 이식성 때문에 편집자를 Revelation으로 가져 와서이를 사용하여 전체 프로젝트를 PC에 구축했습니다.

물론 계시는 PC에 기반을 둔 완벽한 화면 편집기를 가지고 있었으며 80 열을 지났을 때 이의를 제기하지 않았습니다. 그러나 처음 몇 달 동안 저는 그곳에 자신의 편집자를 사용하고 그의 표준.

따라서 첫 번째 표준은 모든 코드 줄에 주석을 달아야한다는 것입니다. 모든 라인. 예외 없음. 그의 근거는 귀하의 의견이 코드에 방금 작성한 내용을 정확하게 말했더라도 의견을 말해야 적어도 라인에 대해 두 번 생각했음을 의미했습니다. 또한 유쾌하게 지적하면서, 줄 끝 주석을 넣을 수 있도록 각 코드 줄을 형식화하는 명령을 편집기에 추가했습니다.

어 그래. 모든 코드 줄에 주석을 달았을 때 줄 주석이있었습니다. 간단히 말해서, 각 줄의 처음 64자는 코드 용이고, 세미콜론이 있었고, 64 자의 문자를 설명하기 위해 15 개의 문자가있었습니다. 요컨대, Pick / Basic 코드를 형식화하기 위해 어셈블리 언어 규칙을 사용하고있었습니다. 이것은 다음과 같은 것들로 이어졌습니다.

EVENT.LIST[DATE.INDEX][-1] = _         ;ADD THE MOST RECENT EVENT
   EVENTS[LEN(EVENTS)]                 ;TO THE END OF EVENT LIST

(실제로, 20 년이 지난 후에 마침내 R / Basic의 줄 연속 구문을 잊어 버렸으므로 다르게 보일 수도 있습니다. 그러나 아이디어를 얻습니다.)

또한 여러 줄 주석을 삽입해야 할 때마다 꽃 상자를 사용하는 것이 규칙이었습니다.

************************************************************************
**  IN CASE YOU NEVER HEARD OF ONE, OR COULDN'T GUESS FROM ITS NAME,  **
**  THIS IS A FLOWER BOX.                                             **
************************************************************************

예, 각 줄마다 별표가 닫혀 있어야합니다. 결국, 그의 편집기를 사용했다면 꽃 상자를 삽입하는 것은 단순한 편집기 명령이었습니다.

Revelation의 빌트인 에디터를 사용하게 해주었습니다. 처음에 그는 규칙이 있었기 때문에 단호했다. 내가 a) 나는 이미 계시록 편집자를 알고 있었다. b) 그것은 그의 편집자보다 실질적으로 더 기능적이었다. c) 다른 요한 계시록 개발자들은 같은 관점을 가질 것이라고, 나는 내가 편집자를 훈련시키지 않으면 나는 그렇지 않을 것이라고 retorted했다. 우리가 알고 있듯이 지옥이 얼어 붙지 않는 한 일어나지 않을 프라임 코드베이스로 작업 할 수 있습니다. 마침내 그는 들어갔다.

그러나 코딩 표준은 마지막이었습니다. 특히 꽃 상자 설명은 어리석은 시간 낭비였으며, 나는 올바른 편집자를 사용하면 완벽하게 쉽게 유지할 수 있다고 말하면서 치아와 손톱에 싸웠습니다. (모든 것이 수동적 공격적이었습니다.) 마침내 나는 조용히 주었고, 그때부터 코드 리뷰에 가져온 모든 코드에는 소중한 꽃 상자 주석이있었습니다.

어느 날, 몇 달 동안 일을 시작했는데, 내가 유능한 것보다 훨씬 더 많이 나 자신을 증명했을 때 (특히 그곳에서 일하는 동안 그 사무실을 통과 한 다른 코더의 퍼레이드와 비교할 때) 그는 내 어깨 너머로보고 있었다. 그는 일했고, 나는 꽃 상자 주석을 사용하지 않는 것을 알았습니다. 오, 나는 주석을 인쇄 할 때 내 의견을 귀하의 스타일로 변환하는 소스 코드 포맷터를 작성했습니다. 편집기에서 유지 관리하는 것보다 쉽습니다. 그는 입을 열고 잠시 생각하고 닫고 사라졌으며 우리는 코딩 표준에 대해 다시 이야기하지 않았습니다. 그 후 우리 두 직업 모두 쉬워졌습니다.


14
인쇄시 주석 포맷터 +1
BradC

1
꽃 상자를 과도하게 사용해서는 안됩니다. 코드를 읽고 읽을 때 나는 그것을 싫어한다. 좋은 의견이다. 그러면 "
이것은

26

첫 직장에서 모든 C 프로그램은 아무리 단순하거나 복잡하더라도 네 가지 기능 만 가지고있었습니다. 당신은 메인을 가지고 있었고, 그것은 다른 세 가지 기능을 차례로 불렀습니다. 나는 그들의 이름을 기억할 수 없지만 begin (), middle () 및 end ()의 줄을 따라 무언가였습니다. begin ()은 파일과 데이터베이스 연결을 열었고 end ()는 닫았으며 middle ()은 다른 모든 작업을 수행했습니다 . 말할 필요도없이 middle ()은 매우 긴 함수였습니다.

그리고 상황을 개선하기 위해 모든 변수는 전역이어야했습니다.

그 직업에 대한 나의 가장 자랑스러운 기억 중 하나는 그 표준의 파괴로 이어진 일반적인 반란의 일부였습니다.


2
나는 회의실에서 종이에 그것이 좋게 들렸다 고 생각한다. 그러나 나는 그것을 따라야하는 프로그래머를 불쌍하게 생각한다
TheLQ

영어 교사가 설계해야합니다.
yodie

COBOL 프로그래머가 설계해야합니다.
bruno

의 많은 것을 사용해야합니다 goto.
새로운 123456

26

규칙에 내장 된 연산자 우선 순위에 의존하지 않고 항상 대괄호를 사용하는 외부 작성 C 코딩 표준

당연히 명백한 의도는 금지하는 것이 었습니다.

a = 3 + 6 * 2;

찬성 :

a = 3 + (6 * 2);

이것은 C 구문 규칙 '=', '==', '.'을 따르는 도구에 의해 시행되었습니다. 배열 액세스는 연산자입니다. 따라서 코드는 다음과 같습니다.

a[i].x += b[i].y + d - 7;

다음과 같이 작성해야했습니다.

((a[i]).x) += (((b[i]).y + d) - 7);

2
아마도 (((a) [(i)]). x) + = (((((bb [(i)]). y) + (d))-(7)); ?
Behrooz
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.