더 긴 "열"코드를 위해 더 짧은 변수 이름을 희생합니까?

나는 적절한 프로그래밍 기술을 배우려고 노력하는 CS 수업의 아마추어 프로그래머입니다. 이것은 내 코드가 어떻게 보이는지, 가장자리는 103 열로 확장됩니다.

int extractMessage(char keyWord[25], char cipherText[17424],
                   int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);


    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }

나는 매우 긴 변수 이름을 갖기 전에 i, j, k와 같은 것을 가지고 있었지만 교수 는 우리가 "전문 세계"에서와 같은 변수를 사용해서는 안되며 lenWord와 같은 단축 된 변수조차도 사람들이 가정 할 수 있기 때문에 불충분하다고 주장합니다. "Lennard 's World Literature"의 약자입니다. 그는 의미있는 변수 이름을 선택하라고 말하지만 그렇게하면 80 열 이하로 유지하기 위해 황금 코딩 규칙을 어긴 것 같습니다. 이 문제를 어떻게 해결합니까?

일반적으로 여기에 게시 된 코드가 표시되면 가로 스크롤이 싫어서 편집합니다. 그러나 이것이 귀하의 질문의 일부이므로 여기에서 편집 내용을 보여 드리겠습니다.

int extractMessage(char keyWord[25], char cipherText[17424],
                   int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);


    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }
}

그 틈은 놀라운 일이 될 수도 있지만, 수평 스크롤 버전보다 더 읽기, 그리고 그것으로 이름을 단축보다 더 나은 i, j그리고 k.

그것은 당신이 사용하지 않을 것이 아니라 i, j하고 k. 이들은 3 개의 중첩 for루프를 색인 할 때 좋은 이름 입니다. 그러나 여기서 이름은 실제로 당신이 일어날 것으로 예상되는 것에 대한 유일한 단서입니다. 특히이 코드는 실제로 아무것도하지 않기 때문에.

변수 이름 길이를 따르는 가장 좋은 규칙은 범위입니다. 변수가 오래 살수록 이름이 경쟁하는 변수가 더 많아집니다. CandiedOrange 라는 이름 은 스택 교환에서 고유합니다. 우리가 대화중이라면 그냥 "캔디"라고 불러 그러나 지금은 그 이름이 Candide , Candy Chiu 또는 Candyfloss 와 혼동 될 수있는 범위에 있습니다 . 따라서 범위가 길수록 이름이 길어집니다. 범위가 짧을수록 이름이 짧아 질 수 있습니다.

줄 길이는 이름 길이를 지시 해서는 안됩니다 . 느낌이 든다면 코드를 배치하는 다른 방법을 찾으십시오. 이를 수행하는 데 도움이되는 많은 도구가 있습니다.

내가 찾은 첫 번째 것 중 하나는 불필요한 잡음을 제거하는 것입니다. 불행히도이 예제는 아무 것도하지 않기 때문에 불필요한 노이즈입니다. 작업 할 무언가가 필요하므로 먼저 무언가를 해보자.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }
    return cipherColumn;
}

거기, 이제 뭔가를합니다.

이제 무언가를했기 때문에 제거 할 수있는 것을 볼 수 있습니다. 이 길이의 물건은 사용되지 않습니다. 이것은 continue아무것도하지 않습니다.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

소스 컨트롤의 세계에 살고 있기 때문에 약간의 공백을 조정 해 봅시다. 라인이 변경된 것으로보고되는 유일한 이유는 라인의 일부가 열에 정렬되어 있어야하기 때문에 다른 무언가를하고 있기 때문입니다.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn = 0;
    int cipherColumn = 0;
    int offset = 1;
    int nextWord = 1;

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

예, 약간 읽기 쉽지는 않지만 vdiff 도구를 사용하여 변경 사항을 감지하는 사람들을 미치게 만들 것입니다.

이제 우리는 줄 길이 제한을 유지하기 위해 가지고있는이 바보 같은 줄 바꿈을 수정 해 봅시다.

int calcCipherColumn(
        char keyWord[25], 
        char cipherText[17424],
        int rowSize, 
        char message[388]
) {
    int keyColumn = 0;
    int keyOffset = 1;

    int nextWord = 1;
    int cipherColumn = 0;
    int cipherOffset = (rowSize * nextWord) + nextWord;

    char key = keyWord[keyColumn];
    char keyNext = keyWord[keyColumn + keyOffset];

    while (key != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyNext != cipherText[cipherColumn + cipherOffset]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

이제 루프의 논리는 루프의 변경 사항에 중점을 둡니다. 실제로,를 제외한 모든 cipherColumn것이 표시 될 수 있습니다 final. 그리고 이봐! 저것 봐. 이제 할 공간이 있습니다.

내가 한 것은 변수를 3 개 더 추가하고 이름을 바꾸고 조금 재정렬하는 것입니다. 그리고 결과는 어리석은 줄 바꿈없이 줄을 짧게 만들었습니다 !=.

물론 이름 key과 keyNext입니다하지 그 설명하지만, 한 번 익숙해 각각, 그 길지 않은 라이브 할, 그리고 가장 중요한 루프에 흥미 것이 아무것도 없습니다. 따라서 그럴 필요는 없습니다. 추가 변수를 도입하여 필요한 경우 이름을 길게 만들 수있는 공간이 생겼습니다. 상황이 변하기 때문에 결국에는 필요할 수도 있습니다. 우리가 호흡 공간을 가지고있는 것이 좋습니다.

또한 라인 길이 제한을 존중하기 위해 입력 매개 변수를 배치하는 Jeff Grigg의 형식 6 변형 스타일을 자유롭게 보여 주었습니다.

다른 사람들은 이미 몇 가지 유용한 제안을했습니다.

• 한 줄에 80자가 80 년대에 황금률이었을 것입니다. 오늘날 대부분의 사람들은 100 자에서 130 자 정도가 좋다는 데 동의합니다.
• 식 안에 줄 바꿈을 사용하십시오.
• 중간 결과를 도입하여 긴 표현을 나눕니다.

나는 다른 추천을 추가하고 싶다 : 긴 이름에 대해 독단적 인 태도를 취하지 마십시오! 변수의 범위가 클수록 이름에 더 많은 정보를 넣어야합니다. 그리고 일반적으로 변수의 범위를 작게 유지하는 것이 좋습니다.

예를 들어 키워드 암호화 테이블의 열에 변수가 있고 변수 범위에이 테이블 만 사용 된 것이 분명한 경우 column또는 을 호출하는 것이 col좋습니다. 범위가 더 크고 여러 테이블이 관련된 경우이를 호출하는 것이 keyWordEncryptionTableColumn좋습니다.

또 다른 예 : 본문이 2 ~ 3 줄에 걸쳐있는 루프가 있고 배열의 요소에 액세스하기 위해 색인을 사용해야하는 경우 index 호출에 아무런 문제가 없습니다 i. 이러한 맥락에서, 그것은 (대부분의 사람들에게) 적어도 (가령)보다 훨씬 읽기 쉽습니다 arrayIndexOfMyVerySpecialDataSet.

나는 일반적으로 선생님과 동의합니다. 그러나 실패한 큰 코드 조각에서 많이 사용할 변수가 있으면 그 의미를 명시 적으로 표현한 후 짧은 형식을 사용하는 것이 좋습니다. 복잡한 산술 표현식과 대입이 많은 경우처럼 변수 이름이 긴 변수는 잘 읽지 못합니다.

개요에 대해 :

ExtractMessage(char keyWord[25], char cipherText[17424],
               int rowSize, char message[388]) 

이것은 목적을 제공하지 않으며, 단지 줄 길이를 제한한다고해서 더 읽기 쉽지 않습니다. 이것을 읽을 수있게하려면 다음을 수행하십시오.

ExtractMessage(
  char keyWord[25],
  char cipherText[17424],
  int rowSize,
  char message[388]
  )
{

그런 다음 유형 식별자를 정렬 할 수도 있습니다 (int 뒤에 공백을 추가하십시오). 그러나 초기화 또는 다음과 같은 인수 목록을 설명 할 때는주의해야합니다.

int keyColumn    = 0;
int cipherColumn = 0;
int offset       = 1;
int nextWord     = 1;

문제는 이름을 변경하거나 변수를 추가 할 때 전체 블록을 다시 포맷해야 예쁘게 보일 수 있습니다. 그것은 의미없는 변화를 도입하는 것만 큼 효과가 없으며 버전 관리 시스템에서는 끔찍할 것입니다. 동료가 파일을 변경 한 것을 확인하고 이전 버전과 비교하여 수행 한 작업을 확인할 수 있습니다. 그런 다음 모든 줄이 변경되면 불이 켜지고 실제 변경 내용이 가려집니다. 실제로 얼마나 나쁜지를 사용하는 비교 도구의 품질에 약간 의존하지만 일반적으로 코드를 너무 개인적으로 만들거나 한 줄의 형식을 다른 줄에 의존시키는 것은 좋은 생각이 아닙니다.

때로는 개요가 목적에 도움이 될 수 있습니다. 거의 동일한 수십 개의 연속적인 선이 있다면, 윤곽을 그려 보면 서로 다른 위치를 쉽게 찾을 수 있습니다.

작업장에서 자동화 된 형식화가 진행되어 버전 관리 시스템에 제출하기 전에 코드에서 수행하는 멋진 형식화를 제거 할 수 있습니다.

면책 조항 : 요점을 분명히하기 위해 조금 과장했습니다. 따라서 소금 한 덩어리로 최상급을 섭취하십시오.

선생님은 100 % 옳습니다 : 더 이상 약 80 자의 "황금 규칙"이 없습니다 (리눅스 코드를 작성하지 않는 한). 이 규칙은 당시 터미널의 크기 때문에 설정되었지만 요즘에는 enditor 창에서 150자를 넘게 쉽게 입력 할 수 있습니다. 그리고 한도를 초과하더라도 편집기는 줄을 부드럽게 감싸서 스크롤 할 필요가 없습니다. 그리고 80자를 넘지 않는 유일한 이유는 스크롤이 필요했기 때문입니다. 입니다.

즉, 실제로 라인을 무한정 성장시킬 필요가 없습니다. 줄이 길수록 사람이 파싱하기가 더 어려워집니다. 그러나 짧은 변수 이름은 긴 행 문제에 대한 해결책이 아닙니다 .

해결 방법은 더 적절하게 명명 된 변수를 도입하여 식을 논리적으로 분할하는 것 입니다. 공백으로 영리하려고하지 마십시오. 적절하게 명명 될 수있는 하위 표현식을 식별하고 이에 대한 변수를 작성하십시오. 변수를 계산하는 코드와 해당 변수를 사용하는 코드를 모두 단순화합니다 .

귀하의 질문의 일부는 아니지만 어쨌든 그것에 대해 언급하고 싶습니다 : =연산자 를 수직으로 정렬하는 것은 매우 나쁜 생각 입니다.

그 이유는 세 가지가 있습니다.

1. 수직으로 정렬 된 연산자를 포함하는 블록을 편집하는 것은 PITA입니다. 가장 큰 변수의 길이가 변경 될 때마다 (이름 바꾸기, 추가, 삭제) "좋은"레이아웃을 다시 얻으려면 블록의 모든 줄을 수정해야합니다.

   물론 유능한 편집기를 사용하여이 문제를 약간 줄일 수 있으므로 사소한 이유입니다. 진짜 이유는 두 번째입니다.

2. 재정렬을 통해 도입 된 이러한 잘못된 공백 변경은와 같은 최신 버전 제어 시스템과 잘 어울리지 않습니다 git. 실제 충돌이 발생하지 않고 정렬을 사용하지 않으면 충돌이 발생하지 않는 상당한 양의 병합 충돌이 발생하는 경향이 있습니다. 이러한 가짜 갈등은 귀중한 시간이 들지 않습니다 .

3. 정렬에는 의미가 전혀 없습니다 . 무의미합니다. 정렬로 더 잘 이해할 수있는 것은 없습니다. 블록의 모든 행은 그 자체로 무엇을 이해해야하는지, 위와 아래의 행에 대한 연결은 순전히 구문 적입니다.

정렬은 의미 적 의미를 갖지 않지만 상당한 비용을 발생 시키므로 더 이상 시간이 걸리기 전에 습관을 익혀야합니다.

80 자 제한을 너무 좋아한다면 포트란 프로그래밍을 시도해보십시오. 사실, 새로운 표준은 포트란 라인 제한을 132 자로 늘 렸지만,이 제한을 초과하는 모든 프로그램의 컴파일을 방해하는 효과가 있습니다. 프로그래밍에 능숙하다면 곧 라인 길이 제한을 포함하여 포트란을 싫어하게 될 것입니다. 그 후, 당신은 당신의 남은 생애 동안 치유 될 것입니다.

나는 스스로 포트란 프로그래밍을 전문적으로 수행해야했으며, 줄 길이 제한을 가장 싫어한다는 것을 가르쳐 주었다. 컴파일러가 더 이상 올바르게 컴파일하지 않기 때문에 간단하고 읽을 수있는 행을 여러 부분으로 분할하는 것보다 더 실망스러운 것은 없습니다. 그리고 한 줄로 표현 될 때 가장 간단한 코드 줄이 있습니다.

프로그래밍 환경의 한계로 인해 수년에 걸쳐 많은 스타일 규칙 (규칙이 아님)이 생겨났습니다. 펀치 카드 일 다시, 당신은 한 하드 (포트란은 줄 연속 문자 열 여섯 예약 된 이유였다) 물리적 소스 행에 표시 할 수있는 문자 수에 제한을. 수십 년 전에 80x24 앰버 온 블랙 VT220 터미널을 작업 한 것은 아니 었습니다. 내가 사용한 편집기는 줄을 80 자로 제한하지 않았지만 가로 스크롤을 피하기 위해 최선을 다하면 인생이 훨씬 쉬워졌습니다.

이전 버전의 Fortran (최대 '77, IINM)에서는 6-8 자 이상의 식별자를 가질 수 없었습니다 . 80 년대 후반이 되더라도 C는 외부 이름의 처음 8자가 의미가 있다는 것을 보증 할뿐입니다 (따라서 일부 라이브러리 함수는 훌륭하게 설명적인 이름을가집니다 strpbrk).

물론, 21 세기에서 20 년 동안 우리는 더 이상 그런 한계가 없습니다. 더 많은 설명 식별자를 사용 하지 않는 이유는 없습니다 .

문제는 적절한 상황에서,이다, i그리고 j하고 k있습니다 완벽하게 합리적인, 의미있는 이름 . 루프에서 배열이나 벡터를 반복하고 현재 요소를 식별하기 위해 무언가가 필요한 경우 i완벽하게 작동합니다. 나는 같은 이름을 사용하지 않을 것입니다. currentElement그것은 그 맥락에서 더 의미가 없으며 시각적 혼란을 더합니다.

말하기를, 선생님은 당신이 모든 것에 대해 더 길고 더 묘사적인 이름으로 생각하도록 강요하는 데 잘못이 아닙니다. 먼저 습관에 빠지면 인생이 더 쉬워 질 것입니다. 사람으로 있었다 8 자 이하로 적합 모든 것을 강제 한 번에, 그것은보다 자세한 내용의 측면에 확실히 더 나은 ERR에 있습니다. 더 많은 경험을 얻으면 식별자 길이를 절약 할 수있는 곳과 좀 더 설명이 필요한 곳을 배웁니다.

이것이 c에 효과가 있는지 확실하지 않지만 수식을 여러 줄로 나눌 수있는 방법이 있습니까? 나는 파이썬과 같은 것을 알고 있습니다.

새 줄에서 + (rowSize * nextWord) + nextWord]) {를 시작할 수 있는지 확인하십시오. (IDE에서 Enter 키를 누르고 들여 쓰기 여부를 확인하면 C가 현재 행에서 이전 표현식이 완료되고 있음을 알 수 있습니다)