Tôi có hy sinh các tên biến ngắn hơn cho mã dài hơn có cột không?

Tôi là một lập trình viên nghiệp dư trong một lớp CS cố gắng học các kỹ năng lập trình phù hợp. Đây là cách mã của tôi trông, các cạnh của nó mở rộng đến 103 cột.

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;
        }
    }

Trước khi tôi có những tên biến siêu dài đó, tôi có những thứ như i, j, k, nhưng giáo sư của tôi khẳng định rằng chúng tôi không sử dụng các biến như thế trong "thế giới chuyên nghiệp" và thậm chí các biến rút ngắn như lenWord là không đủ vì mọi người có thể cho rằng nó là viết tắt của "Văn học thế giới của Lennard". Anh ta nói chọn các tên biến có ý nghĩa nhưng bằng cách đó tôi cảm thấy như mình đã phá vỡ Quy tắc vàng về mã hóa để giữ nó dưới 80 cột. Làm thế nào để tôi có được xung quanh này?

Thông thường khi tôi thấy mã được đăng ở đây giống như của bạn, tôi chỉnh sửa nó, vì chúng tôi ghét cuộn ngang. Nhưng vì đó là một phần câu hỏi của bạn, tôi sẽ chỉ cho bạn chỉnh sửa ở đây:

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;
        }
    }
}

Nghỉ mà bạn có thể ngạc nhiên, nhưng nó dễ đọc hơn so với phiên bản cuộn ngang, và đó là tốt hơn so với rút ngắn tên để i, jvà k.

Nó không phải là bạn không bao giờ nên sử dụng i, jvà k. Đó là những cái tên đẹp khi lập chỉ mục 3 forvòng lặp lồng nhau . Nhưng ở đây, những cái tên thực sự là manh mối duy nhất của tôi về những gì bạn dự kiến ​​sẽ xảy ra. Đặc biệt là vì mã này không thực sự làm gì cả.

Quy tắc tốt nhất để làm theo chiều dài tên biến là phạm vi. Cuộc sống biến càng dài, tên biến của nó càng phải cạnh tranh. Tên CandiedOrange là duy nhất trên trao đổi ngăn xếp. Nếu chúng tôi đang trò chuyện, bạn có thể gọi tôi là "Candy". Nhưng ngay bây giờ, bạn đang ở trong một phạm vi mà tên đó có thể bị nhầm lẫn với Candide , Candy Chiu hoặc Candyfloss . Vì vậy, phạm vi càng dài, tên càng dài. Phạm vi càng ngắn, tên càng ngắn.

Độ dài dòng không bao giờ chỉ ra chiều dài tên. Nếu bạn cảm thấy như vậy thì hãy tìm một cách khác để trình bày mã của bạn. Chúng tôi có nhiều công cụ để giúp bạn làm điều đó.

Một trong những điều đầu tiên tôi tìm kiếm là tiếng ồn không cần thiết để loại bỏ. Thật không may, ví dụ này không làm gì cả, vì vậy tất cả đều là tiếng ồn không cần thiết. Tôi cần một cái gì đó để làm việc với vì vậy trước tiên hãy làm cho nó làm một cái gì đó.

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;
}

Ở đó, bây giờ nó làm một cái gì đó.

Bây giờ nó làm một cái gì đó, tôi có thể thấy những gì tôi có thể thoát khỏi. Thứ chiều dài này thậm chí không được sử dụng. Điều này continuecũng không làm gì cả.

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;
}

Chúng ta hãy thực hiện một số điều chỉnh không gian trắng nhỏ, bởi vì chúng ta sống trong một thế giới kiểm soát nguồn và thật tuyệt khi lý do duy nhất một dòng được báo cáo là thay đổi là vì nó làm một cái gì đó khác nhau, không phải vì một phần của nó phải xếp hàng trong một cột.

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;
}

Vâng, tôi biết nó hơi khó đọc nhưng nếu không, bạn sẽ khiến mọi người phát điên khi sử dụng các công cụ vdiff để phát hiện các thay đổi.

Bây giờ chúng ta hãy sửa những ngắt dòng ngớ ngẩn mà chúng ta có bởi vì chúng ta đang cố gắng duy trì giới hạn độ dài của dòng.

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;
}

Ở đó, bây giờ logic trong vòng lặp được tập trung vào những gì thay đổi trong vòng lặp. Trong thực tế, tất cả mọi thứ ngoại trừ cipherColumncó thể được đánh dấu final. Và này! Nhìn kìa. Bây giờ chúng ta có chỗ để làm điều đó.

Tất cả những gì tôi đã làm là thêm 3 biến nữa, đổi tên một và sắp xếp lại chúng một chút. Và kết quả chỉ xảy ra để làm cho các dòng đủ ngắn để phù hợp mà không có một dòng ngắt ngớ ngẩn trên !=.

Chắc chắn tên keyvà keyNextkhông phải là mô tả, nhưng mỗi cái chỉ được sử dụng một lần, không sống lâu như vậy và quan trọng nhất là không làm bất cứ điều gì thú vị trong vòng lặp. Vì vậy, họ không cần phải như vậy. Bằng cách giới thiệu các biến phụ, giờ đây chúng ta có chỗ để đặt tên của chúng dài nếu chúng ta cần. Mọi thứ thay đổi, vì vậy cuối cùng chúng ta có thể cần phải. Nếu chúng ta làm, thật tốt khi chúng ta có phòng thở.

Tôi cũng có quyền tự do chỉ cho bạn kiểu biến thể mẫu 6 của Jeff Grigg trong việc đưa ra các tham số đầu vào để tôn trọng các hạn chế độ dài dòng.

Những người khác đã đưa ra một số gợi ý hữu ích, hãy để tôi tóm tắt:

• 80 ký tự trên mỗi dòng có thể là một quy tắc vàng trong thập niên 80. Ngày nay hầu hết mọi người đều đồng ý rằng 100 đến 130 ký tự là ổn.
• Sử dụng ngắt dòng bên trong biểu thức của bạn.
• Chia biểu thức dài bằng cách giới thiệu kết quả trung gian.

Tôi muốn thêm một đề nghị khác: Đừng giáo điều về những cái tên dài! Phạm vi của một biến càng lớn, càng nhiều thông tin phải được đặt vào tên của nó. Và nói chung, đó là một ý tưởng tốt để giữ phạm vi của các biến nhỏ.

Ví dụ: nếu bạn có một biến cho cột của bảng mã hóa từ khóa và rõ ràng là chỉ có một bảng này được sử dụng trong phạm vi của biến của bạn, bạn có thể gọi nó columnhoặc thậm chí là ổn col. Nếu phạm vi lớn hơn và có nhiều bảng liên quan, thì gọi nó là hợp lý keyWordEncryptionTableColumn.

Một ví dụ khác: Nếu bạn có một vòng lặp với phần thân trải dài hai hoặc ba dòng và phải sử dụng một chỉ mục để truy cập các phần tử của một mảng, thì không có gì sai khi gọi chỉ mục i. Trong bối cảnh này, nó dễ đọc hơn nhiều (đối với hầu hết mọi người ít nhất) hơn là, nói arrayIndexOfMyVerySpecialDataSet.

Tôi thường đồng ý với bạn giáo viên. Tuy nhiên, nếu bạn có một biến mà bạn sẽ sử dụng rất nhiều trong một đoạn mã lớn, thì tốt hơn là sử dụng một dạng tốc ký cho nó sau khi rõ ràng về ý nghĩa của nó. Giống như khi bạn có rất nhiều biểu thức và bài tập số học phức tạp, chúng không đọc tốt với tên biến dài.

Về phác thảo:

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

Điều này không phục vụ mục đích, chỉ giới hạn độ dài dòng không làm cho nó dễ đọc hơn. Nếu bạn muốn điều này có thể đọc được, hãy làm điều này:

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

Và sau đó bạn thậm chí có thể muốn căn chỉnh các định danh loại (thêm khoảng trắng sau int). Tuy nhiên, hãy cẩn thận / hạn chế với các danh sách lập luận hoặc danh sách đối số như thế này:

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

Vấn đề là khi bạn thay đổi tên hoặc thêm một biến, bạn có thể phải định dạng lại toàn bộ khối để duy trì giao diện đẹp. Nó không dành cho công việc nhiều như những thay đổi vô nghĩa mà bạn sẽ giới thiệu, nó sẽ trông thật kinh khủng trong một hệ thống kiểm soát phiên bản. Đồng nghiệp của bạn sẽ thấy bạn thay đổi tệp và làm khác với phiên bản trước để xem bạn đã làm gì. Sau đó, mỗi dòng sẽ sáng lên khi thay đổi, che khuất sự thay đổi thực sự. Nó sẽ phụ thuộc một chút vào chất lượng của công cụ so sánh được sử dụng, điều này thực sự tệ đến mức nào nhưng nói chung, không nên để mã quá cá nhân và / hoặc định dạng của một dòng phụ thuộc vào dòng khác.

Đôi khi phác thảo có thể phục vụ một mục đích, nếu bạn có hàng chục dòng liên tiếp gần giống nhau, sẽ dễ dàng nhận ra chúng khác nhau ở đâu nếu bạn phác thảo chúng.

Lưu ý rằng một nơi làm việc có thể có một số định dạng tự động đang diễn ra sẽ xóa bỏ mọi định dạng ưa thích mà bạn thực hiện đối với mã của mình trước khi gửi nó đến hệ thống kiểm soát phiên bản.

Tuyên bố miễn trừ trách nhiệm: Tôi đang phóng đại một chút ở đây để làm cho quan điểm của tôi rõ ràng hơn. Vì vậy, lấy bất kỳ so sánh với một hạt muối.

Giáo viên của bạn đúng 100%: Không còn "quy tắc vàng" nào về 80 ký tự nữa (trừ khi bạn đang viết mã linux, nghĩa là như vậy). Quy tắc đó được thiết lập vì kích thước của các thiết bị đầu cuối tại thời điểm đó, nhưng ngày nay, bạn dễ dàng nhồi nhét hơn 150 ký tự trong cửa sổ enditor của bạn. Và ngay cả khi bạn vượt quá giới hạn đó, trình soạn thảo của bạn sẽ hy vọng bọc mềm dòng để bạn không phải cuộn. Và lý do duy nhất để không vượt quá 80 ký tự là nhu cầu cuộn .

Điều đó nói rằng, thực sự không cần thiết phải để dòng của bạn phát triển vô hạn. Dòng càng dài, con người càng khó phân tích. Nhưng tên biến ngắn không phải là phương thuốc cho vấn đề dài dòng .

Biện pháp khắc phục là phân chia các biểu thức của bạn một cách hợp lý bằng cách giới thiệu các biến được đặt tên chính xác hơn . Đừng cố tỏ ra thông minh với khoảng trắng. Chỉ cần xác định bất kỳ biểu thức con nào có thể được đặt tên một cách khéo léo và tạo một biến cho nó. Điều đó đơn giản hóa cả mã tính toán biến và mã sử dụng biến đó .

Không phải là một phần của câu hỏi của bạn, nhưng dù sao tôi cũng muốn bình luận về nó: Đó là một ý tưởng rất tồi để sắp xếp theo chiều dọc các =toán tử của bạn .

Có ba lý do cho điều đó:

1. Chỉnh sửa một khối chứa các toán tử được phân bổ theo chiều dọc là một PITA. Bất cứ khi nào độ dài của biến lớn nhất thay đổi (đổi tên, thêm, xóa), bạn cần chỉnh sửa lại tất cả các dòng trong khối để lấy lại bố cục "đẹp" của bạn.

   Tất nhiên, vấn đề này có thể được giảm bớt một chút bằng cách sử dụng một trình soạn thảo có thẩm quyền, vì vậy đó là lý do nhỏ. Lý do thực sự là thứ hai:

2. Những thay đổi khoảng trắng giả được giới thiệu bằng cách sắp xếp lại không chơi độc đáo với các hệ thống kiểm soát phiên bản hiện đại như thế nào git. Họ có xu hướng tạo ra một số lượng đáng kể các xung đột hợp nhất trong đó không có xung đột thực sự xảy ra và nơi không có xung đột sẽ được báo hiệu nếu không sử dụng căn chỉnh. Mỗi xung đột giả này sẽ khiến bạn mất thời gian quý báu .

3. Sự liên kết mang ý nghĩa ngữ nghĩa bằng không . Nó là vô nghĩa. Không có gì mà bạn có thể hiểu rõ hơn với sự liên kết. Mỗi dòng trong khối của bạn cần phải tự đọc để hiểu những gì nó làm, kết nối với các dòng trên và dưới đây hoàn toàn là bản chất cú pháp.

Vì sự liên kết không mang bất kỳ ý nghĩa ngữ nghĩa nào, nhưng tạo ra chi phí đáng kể, bạn nên bỏ thói quen này trước khi nó làm bạn tốn thêm thời gian.

Nếu bạn thích giới hạn 80 ký tự rất nhiều, hãy thử lập trình fortran. Đúng như vậy, các tiêu chuẩn mới hơn đã nâng giới hạn dòng fortran lên 132 ký tự, nhưng nó vẫn có hiệu lực khi làm tê liệt việc biên dịch của bất kỳ chương trình nào vượt quá giới hạn. Nếu bạn giỏi lập trình, bạn sẽ sớm ghét fortran, bao gồm cả giới hạn độ dài dòng của nó. Sau đó, bạn sẽ được chữa lành cho đến hết đời.

Bản thân tôi đã phải thực hiện một số chương trình fortran một cách chuyên nghiệp, và tôi nói với bạn, nó đã dạy tôi ghét giới hạn chiều dài đó một cách thân thương nhất. Hoàn toàn không có gì bực bội hơn việc phải chia một dòng đơn giản và dễ đọc khác thành các phần chỉ vì trình biên dịch sẽ không biên dịch chính xác nữa. Và chắc chắn có những dòng mã đơn giản nhất khi chúng được thể hiện dưới dạng một dòng duy nhất.

Rất nhiều quy ước về phong cách (không phải quy tắc!) Nảy ra trong nhiều năm do những hạn chế trong môi trường lập trình. Trở lại trong những ngày đấm thẻ, bạn đã có một cứng giới hạn về số lượng ký tự có thể xuất hiện trên một dòng nguồn vật lý (đó là lý do tại sao Fortran reserved cột 6 cho các ký tự tiếp tục dòng). Không phải là nhiều thập kỷ trước, tôi đã làm việc trên một thiết bị đầu cuối VT220 màu hổ phách 80x24; trong khi các trình soạn thảo tôi đã sử dụng không giới hạn dòng đến 80 ký tự, cuộc sống sẽ dễ dàng hơn rất nhiều nếu bạn cố hết sức để tránh cuộn ngang.

Trong các phiên bản cũ hơn của Fortran (tối đa '77, IINM), bạn thậm chí không thể có số nhận dạng dài hơn 6 đến 8 ký tự. Ngay cả vào cuối thập niên 80, C chỉ đảm bảo rằng 8 ký tự đầu tiên trong tên bên ngoài là có ý nghĩa (đó là lý do tại sao một số chức năng thư viện có tên mô tả tuyệt vời như thế strpbrk).

Tất nhiên, hai thập kỷ đến thế kỷ 21, chúng ta không còn những giới hạn đó nữa. Không có lý do gì để không sử dụng các định danh mô tả nhiều hơn.

Có điều là, trong bối cảnh phải, ivà jvà klà hoàn toàn hợp lý, tên có ý nghĩa . Nếu tôi lặp qua một mảng hoặc một vectơ trong một vòng lặp và tôi chỉ cần một cái gì đó để xác định phần tử hiện tại, ihoạt động hoàn toàn tốt. Tôi sẽ không sử dụng một cái tên như currentElement- nó không có ý nghĩa hơn trong bối cảnh đó và nó chỉ thêm sự lộn xộn thị giác.

Như đã nói, giáo viên của bạn không sai khi buộc bạn phải suy nghĩ về những cái tên mô tả dài hơn cho mọi thứ - cuộc sống sẽ dễ dàng hơn cho bạn nếu bạn tập thói quen đó trước, và sau đó học cách tiết kiệm khi cần thiết. Là một người từng có lúc buộc phải ghép mọi thứ thành 8 ký tự hoặc ít hơn, chắc chắn tốt hơn là sai ở phía nhiều thông tin hơn là ít hơn. Khi bạn có được nhiều kinh nghiệm hơn, bạn sẽ tìm hiểu nơi bạn có thể tiết kiệm chi phí cho độ dài định danh và nơi bạn cần mô tả thêm một chút.

Tôi không chắc liệu điều này có hiệu quả với c hay không nhưng có cách nào để phân chia công thức trên nhiều dòng không? Tôi biết một cái gì đó như thế tồn tại cho python.

Xem bạn có thể bắt đầu + (rowSize * nextWord) + nextWord]) {trên một dòng mới. (Giống như nhấn enter trong IDE của bạn và xem nếu nó thụt lề để C biết rằng biểu thức trước đó đang được hoàn thành trên dòng hiện tại)