Lý do đặt loại hàm và tên phương thức trên các dòng khác nhau trong C

Tôi mới bắt đầu tại một công ty và một trong những nhận xét về phong cách trong bài đánh giá mã đầu tiên của tôi là loại trả về và tên phương thức phải nằm trên các dòng khác nhau. Ví dụ, cái này

void foo() {
}

nên là cái này

void
foo() {
}

Tôi đã luôn sử dụng phong cách đầu tiên, và tôi đã tự hỏi liệu có lý do nào khác ngoài sở thích cá nhân tại sao mọi người sử dụng phong cách thứ hai không? Tôi không nghĩ rằng cái đầu tiên làm tổn thương khả năng đọc. Là một phổ biến hơn so với cái khác với các lập trình viên C và các dự án nguồn mở lớn?

đã tự hỏi nếu có bất kỳ lý do khác ngoài sở thích cá nhân tại sao mọi người sử dụng phong cách thứ hai?

Đó là một phong cách đã trở lại phổ biến trong những ngày đầu của C, vì vậy lý do có thể là vì họ đã làm nó trong một thời gian rất dài, họ đã có rất nhiều mã giống như vậy, và đó là những gì mọi người đều quen Không có nhiều sở thích cá nhân như động lực của công ty.

Một lý do khác là tên hàm luôn bắt đầu trong cột đầu tiên. Các kiểu trả về có độ dài khác nhau và có thể hơi phức tạp - việc đặt loại trên dòng riêng của nó làm cho tên hàm dễ tìm hơn.

Nếu công ty có một phong cách thiết lập, họ cũng có thể có một tài liệu tiêu chuẩn mã hóa. Yêu cầu nó. Nó có thể giải thích (các) lý do cho lựa chọn này và việc có một bản sao sẽ giúp bạn tránh các vấn đề tương tự trong các đánh giá trong tương lai.

Đây là khá nhiều quy tắc định dạng mã duy nhất mà tôi đã tìm thấy thực sự có tác động đáng chú ý đến khả năng đọc và hầu như không mất công sức (giả sử trình soạn thảo mã của bạn không bắt đầu cuộc chiến với bạn về nó).

Đó là thiết kế ngôn ngữ lập trình tốt để có tên xuất hiện ở vị trí nhất quán trong khai báo / định nghĩa. Cơ sở lý luận rất đơn giản: bạn có một mỏ neo trực quan đẹp (nẹp xoăn hoặc chỉ là một vết lõm treo) mà bạn có thể sử dụng để tìm ngay phần đầu của tên. Bạn không cần phải phân tích ngôn ngữ khi quét qua tệp tìm tên.

Nó giống như khi bạn định dạng một tài liệu: khi bạn bắt đầu một phần mới, bạn đặt tên lên phía trước in đậm - thường trên dòng riêng của nó - không bị chôn vùi ở đâu đó, không phân biệt, trong một câu dài.

Đầu C có chữ ký rất ngắn gọn: kiểu trả về là tùy chọn và kiểu đối số được khai báo sau chữ ký. Tên cũng có xu hướng rất ngắn. Điều này giảm nhẹ tác động của việc có một loại trả lại thỉnh thoảng bù đắp tên.

double dot(x, y);

Vẫn còn tiêu hóa.

C ++ làm cho điều này tồi tệ hơn một chút. Nó chuyển các đặc tả loại đối số thành chữ ký làm cho chữ ký dài hơn. Cú pháp này sau đó đã được thông qua trong quá trình tiêu chuẩn hóa C.

static struct origin *find_origin(struct scoreboard *sb,
                  struct commit *parent,
                  struct origin *origin)

ít tiêu hóa, nhưng không quá tệ. (Trích từ Git)

Bây giờ hãy xem xét các thực tiễn lập trình hiện đại với các tên dài, mô tả và các loại tham số và xem lựa chọn này đã trở thành thảm họa như thế nào. Một ví dụ từ tiêu đề Boost:

template <class A1, class A2, class A3, class A4, class A5, class A6>
inline typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type make_policy(const A1&, const A2&, const A3&, const A4&, const A5&, const A6&)
{ 
   typedef typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type result_type;
   return result_type(); 
}

Nếu bạn đang viết mã chung, chữ ký như thế thậm chí không bình thường. Bạn có thể tìm thấy các ví dụ về các trường hợp tồi tệ hơn nhiều so với điều này mà không cần cố gắng quá nhiều.

C, C ++ và các dẫn xuất của chúng, Java và C #, dường như là ngoại lệ để có các khai báo / định nghĩa có thể đọc được. Người tiền nhiệm và đồng nghiệp nổi tiếng của họ (Fortran, ALGOL, Pascal) đã đặt tên trước các loại kết quả và, may mắn thay, nhiều người kế nhiệm của họ (Go, Scala, TypeScript và Swift để đặt tên cho một số) cũng đã chọn các cú pháp dễ đọc hơn.

Lần đầu tiên tôi gặp phong cách này vào năm thứ 19 làm việc với C & C ++. Đã có khá nhiều trở ngại về việc ai đó có thể phát minh ra điều xấu xa này.

Điểm tích cực duy nhất (có khả năng) tôi có thể tìm thấy là bạn có thể tìm thấy định nghĩa funciton bằng grep ^ FuncName. Có thể là yếu tố có liên quan thập kỷ + trước đây trong một số cộng đồng ghét công cụ thực sự ... Tại nơi tôi thấy nó được áp dụng cho C ++ và các funcitons thành viên lớp, điều đó giết chết ngay cả thuộc tính này.

Đoán ý kiến ​​của tôi. :)