Có phải là một ý tưởng tồi để liệt kê mọi đối số hàm / phương thức trên một dòng mới và tại sao?

Tôi làm việc với ai đó, mỗi khi họ gọi một hàm, họ đặt các đối số trên một dòng mới, vd

aFunction(
    byte1,
    short1,
    int1, 
    int2,
    int3,
    int4,
    int5
) ;

Tôi thấy điều này rất khó chịu vì nó có nghĩa là mã không gọn lắm, vì vậy tôi phải quét lên xuống nhiều hơn để thực sự hiểu được logic. Tôi muốn biết liệu đây có phải là thực tế xấu hay không và nếu vậy, làm thế nào tôi có thể thuyết phục họ không làm điều đó?

Nó chỉ là một hướng dẫn mã hóa mà bạn có thể hoặc không thể thích. Điều quan trọng là bạn và đồng nghiệp có đồng ý sử dụng hay không.

Rõ ràng, cách tốt nhất để tăng khả năng đọc là hạn chế số lượng đối số.

Đó là một vấn đề ưu tiên. Đối với các cuộc gọi hàm phức tạp, nơi bạn muốn ghi lại từng tham số hoặc nơi các biến khá dài và có nhiều trong số chúng, điều này có thể tốt.

Ví dụ:

do_complex_op(
      0, //Starting state, always 0, ask Joe why
      X, //X-coord of thingy
      y, //Y-coord of thingy
      73, //in this case, we don't want to use Z but want constant 
      dlogMessageTitle, //message for dialogue title
      dlogMessageText, //message for dialogue contents, don't care about this.
      SomethingIP, //IP of something-or-other server, can be NULL, won't crash.
      someObject.childObject.getValue(key1).HVAL, //very long path to HVAL
      someObject.childObject.getValue(key1).LVAL, //very long path to LVAL
      this.parentWindow.owner.mainTextBox.text.value.trim, //get the trimmed text, untrimmed text causes weird output
      pvrMainSettingForLongBlahs.getObjectByPath(somePath),
      pvrMainSettingForLongBlahs.K_TCA_UPPER_LIMIT,
      pvrMainSettingForLongBlahs.K_ENDPOINT_COMPLIANCE_LEVEL,
 );

Với các ngôn ngữ cho phép các tham số được đặt tên, điều này phổ biến hơn nếu bạn sử dụng tên tham số (ví dụ là trong PL / SQL):

PKG_SOME_TEST_CODE.FN_DO_SOMETHING( in_text => 'test text',
                                    in_id => v_id,
                                    in_ref_id => v_ref_id,
                                    out_array_for_storage => v_bArray); 

Nhưng tôi đồng ý với bạn rằng nếu lệnh gọi hàm đơn giản và không có quá nhiều tham số, điều này có thể gây khó chịu, chẳng hạn như:

setColour (
    r,
    g,
    b
 );

Tôi thấy dễ đọc hơn nhiều

 setColour(r,g,b);

Dành cho @ammoQ:

rc=a(b,c(d,e(f)))

rc=a(
     b,
     c(
       d,
       e(
         f
        )
      )
    )

IMO tất cả mọi thứ không phổ biến là thực tiễn xấu trừ khi sự vượt trội so với phong cách thông thường có thể được chứng minh tích cực. Matter của vấn đề Hương vị là một cái cớ nghèo nàn để viết mã khó đọc hơn mức cần thiết cho phần lớn các lập trình viên, bởi vì một ngày, một tâm hồn nghèo nàn, không quen với phong cách đó, sẽ phải duy trì mã đó.

Chứng tỏ rằng nó không phổ biến, tương đối dễ dàng, hiển thị nguồn ví dụ trong MSDN hoặc các trang tương tự, hiển thị các cơ sở mã nguồn mở lớn, v.v. Hiển thị đầu ra của các trình làm đẹp mã. Cuối cùng, cho thấy mọi người khác trong nhóm của bạn đang làm điều đó như thế nào. Đừng chấp nhận một phong cách xấu chỉ vì ai đó quá cứng đầu.

Vâng, đây là một số mồi câu. Tôi chưa bao giờ bị buộc tội làm điều phổ biến. Rõ ràng, nếu mọi thứ phù hợp trên một dòng, thì tốt, phù hợp với chúng trên một dòng.

Nhưng mối quan tâm chính của tôi không phải là mã "xấu" hay "đẹp". Mối quan tâm chính của tôi là làm thế nào dễ hiểu và thực hiện các thay đổi mà không phạm sai lầm.

Nếu các đối số dài và có rất nhiều trong số họ, tại sao không đặt chúng trên các dòng riêng biệt? Theo suy nghĩ của tôi, điều đó giúp dễ dàng nhìn thấy những gì họ đang có, và dễ dàng thay đổi chúng nếu cần thiết. Nó cũng cho tôi chỗ để đính kèm một bình luận cho mỗi đối số nếu tôi muốn.

Tôi cũng muốn giảm thiểu khả năng mắc lỗi nếu tôi thêm hoặc xóa đối số cho hàm, điều này có nhiều khả năng xảy ra ở cuối danh sách đối số so với lúc ban đầu. Vì lý do đó, tôi thích đặt dấu phẩy (,) ở đầu dòng hơn là ở cuối. Sau đó, nếu tôi muốn xóa hoặc thêm một đối số ở cuối danh sách, thì đó là chỉnh sửa một dòng. Tôi không cần phải loay hoay với dấu phẩy cần đi ở cuối tất cả các dòng nhưng cuối cùng, trong đó cuối cùng phải kết thúc bằng dấu ngoặc đơn.

Vì vậy (chàng trai, tôi sẽ nổi bần bật vì điều này) Tôi viết nó như thế này:

nameOfFunction(firstArgument
    , secondArgument // optional comment
       ...
    , lastArgument   // optional comment
    );

Khi có một hàm với từ năm đến hai mươi đối số, hàm sẽ không có được cách đó cùng một lúc. Nó phát triển theo thời gian, có nghĩa là có rất nhiều chỉnh sửa. Bất kỳ chỉnh sửa nào không hoàn thành là lỗi cú pháp hoặc lỗi. Vì vậy, tôi không khẳng định điều này là đẹp. Tôi khẳng định nó giúp ích trong việc chỉnh sửa đúng.

.

Tôi cũng sẽ không gọi nó. Thực hành tốt nhất nơi tôi từng làm việc thường có các cuộc gọi chức năng là tất cả trên một dòng, trừ khi bạn sẽ phải cuộn theo chiều ngang bất kỳ số lượng đáng kể nào để xem toàn bộ cuộc gọi. Đó là một cuộc gọi phán xét, nhưng tôi chắc chắn sẽ nói rằng để đặt tất cả các chức năng như thế này là không phù hợp trừ khi đó là tiêu chuẩn được thiết lập bởi tổ chức của bạn.

Đây là lý do tại sao một tổ chức nên thiết lập một bộ hướng dẫn mà tất cả các lập trình viên nên tuân thủ. Đó là tất cả về tính nhất quán và dễ đọc.

Nó làm cho nó dễ dàng hơn:

• Sắp xếp lại các đối số.
• Nhận xét hoặc vô hiệu hóa các đối số.
• Xem chính xác đối số nào đã thay đổi khi bạn xem diffs trong hệ thống kiểm soát phiên bản của bạn
• Tránh thụt lại và gói từ mọi thứ khi bạn thêm hoặc xóa đối số hoặc thay đổi tên hàm. (Ngay cả khi trình soạn thảo của bạn tự động thụt lề, bạn vẫn đang tạo ra nhiều thay đổi khoảng trắng không hữu ích, điều này khiến việc theo dõi các thay đổi trong hệ thống kiểm soát phiên bản của bạn trở nên khó khăn hơn.)

Tôi sẽ nói rằng các lệnh gọi hàm phải là tất cả trên một dòng trừ khi chúng vượt quá đáng kể độ rộng mã tiêu chuẩn của bạn (thường là 80 ký tự, thường là nguyên nhân của các đối số :-).

Tôi không thấy bất kỳ lợi thế cho phong cách này. Nó trông có vẻ chủ quan xấu, và tôi thấy nó là một nỗi đau khi tìm kiếm mã. Chẳng hạn, bạn có thể muốn nhanh chóng tìm kiếm và xem liệu hàm có được gọi với một tham số nhất định được truyền dưới dạng NULL không. Điều này dễ dàng trực quan khi tất cả các tham số nằm trên một dòng và khó hơn khi chúng được phân chia như thế này.

Tôi thường thấy phong cách đó trên các khai báo hoặc định nghĩa hàm , nhưng không bao giờ trên một cuộc gọi (cho đến bây giờ). Đôi khi nó có ý nghĩa vì nó cho phép bạn thêm một nhận xét cho các tham số riêng lẻ rõ ràng hơn. Có vẻ như anh ta đã sao chép phong cách đó vào các cuộc gọi mà không thực sự biết lý do tiềm ẩn đằng sau nó. Bạn có một lý lẽ tốt để chống lại và anh ta dường như không có một lý do tốt, vì vậy bạn có phiếu bầu của tôi, nhưng tôi không phải là người bạn phải thuyết phục.

Có phải nó chống lại các tiêu chuẩn mã hóa của công ty?

Nếu không, sau đó bắt đầu một cuộc thảo luận về các tiêu chuẩn và những gì mọi người muốn thấy đã thay đổi. Hãy chắc chắn rằng bạn đưa ra điều này như một trong những điều bạn muốn thay đổi.

Có một cuộc thảo luận đầy đủ về lý do tại sao bạn không nghĩ rằng điều này hữu ích và hy vọng bạn sẽ giành chiến thắng trong ngày. Bạn không bao giờ biết đồng nghiệp của bạn có thể thuyết phục bạn rằng cách của anh ấy là tốt nhất sau tất cả;)

Khi bạn đã có một tiêu chuẩn được cập nhật rồi, nó sẽ ghi lại những gì mọi người nên mã hóa, vì vậy nếu đồng nghiệp của bạn vẫn kiên trì thực hiện điều này, bạn có thể nâng cao nó trong các đánh giá mã của anh ấy.

Nó có thể trông thú vị với bạn nhưng nó làm cho việc viết mã dễ dàng hơn. Trong khi tái cấu trúc, bạn có thể nhận xét các đối số riêng lẻ rất dễ dàng và kiểm tra cấu trúc lại trước khi thực sự xóa mọi thứ. Bạn cũng có thể bình luận và tạm thời thay thế các loại khá dễ dàng.

Nó cũng dễ đọc hơn:

int f(int, int, int,
      char, double, int
      X const&, Y)
{}

Tôi đã không cực kỳ như bạn đang hiển thị (vì không có tên trên các tham số nên nó không được sử dụng nhiều), nhưng tôi đã có thói quen chia tách từng tham số trên dòng riêng của mình hoặc không thực hiện phân tách.

Phần quan trọng là mã của bạn có thể được in hoặc hiển thị trên màn hình tiêu chuẩn, 80col và vẫn dễ đọc.

Bạn sẽ hiếm khi nhận được một câu trả lời trung thực từ một lập trình viên cho một cái gì đó như thế này. Mọi người sẽ chỉ trả lời với những gì họ làm hoặc không thích. Sự thật là đôi khi tất cả chúng ta đều phải vật lộn với nó, "thực hành xấu" duy nhất ở đây là sự không linh hoạt của chính bạn.

Bạn phải thành thật một cách tàn nhẫn với chính mình để có thể phân biệt giữa những điều thực sự xấu và những điều chỉ làm bạn khó chịu. Sự thật là trong C / C ++ và các ngôn ngữ tương tự, bạn sẽ hiếm khi tìm thấy một thực hành thụt đầu dòng có ảnh hưởng hữu hình đến sự dễ hiểu của mã. Hầu hết các cuộc thảo luận về những điều này chỉ có cả hai bên chồng chất với những người đưa ra những lập luận lố bịch, không lịch sự để cố gắng biện minh cho sở thích cá nhân của riêng họ.

Theo tôi đọc ... chính xác là những gì bạn yêu cầu trong câu hỏi này: một lập luận lố bịch, không lịch sự để biện minh cho sở thích cá nhân của bạn.

Thành thật mà nói, nó phụ thuộc vào từng người .. Tôi muốn nói về các hàm phức tạp như được minh họa bởi ví dụ đầu tiên của FrustratedWithForms, sau đó có; nếu không thì KHÔNG lớn. Sau đó, đây là lý do tại sao tôi thích áp dụng chức năng IDE của mã tùy ý.

"Tôi quan tâm để biết liệu đây có phải là thực tế xấu ..."

Vâng, đó là thực tế xấu, ngoại trừ khi danh sách các biến dài bất thường. Nhưng trong trường hợp đó, vấn đề có thể là do thiết kế của chức năng. Tại sao không vượt qua một đối tượng gói gọn nhiều tham số?

"... và nếu vậy, làm thế nào tôi có thể thuyết phục họ không làm điều đó?"

Buộc chúng xuống và tiếp tục cù chúng cho đến khi chúng đồng ý ngăn chặn chuyện tào lao đó.

Tại sao bạn lãng phí chu kỳ vào một mối quan tâm tầm thường như vậy? Chỉ cần kích hoạt IDE đáng tin cậy của bạn, mở tệp và định dạng lại. Voila! Nó sẽ ở bất cứ hình thức nào bạn muốn.

Bây giờ chúng ta hãy chuyển sang vấn đề thực sự quan trọng - vi hoặc emacs, LOL.

Tôi sẽ nói, nếu các đối số phù hợp trên một dòng, làm như vậy. Nếu không, thì một đối số trên mỗi dòng làm cho khả năng đọc tuyệt vời.

foo(arg1, arg2, arg3, arg4, arg5)

so với

foo(
    arg1=arg1,
    arg2=arg2,
    arg3=arg3,
    arg4=arg4,
    arg5=arg5,
    arg6=arg6,
    arg7=arg7
)