Tôi biết rằng nó đã được chứng minh rằng một tiêu chuẩn mã hóa giúp rất nhiều. Tuy nhiên, có nhiều công cụ và IDE khác nhau sẽ định dạng theo bất kỳ tiêu chuẩn nào mà lập trình viên thích. Miễn là mã gọn gàng / nhận xét (và không phải là mớ hỗn độn spaghetti), tôi không thấy sự cần thiết của một tiêu chuẩn mã hóa.

Có bất kỳ đối số nào cho sự phát triển của một tiêu chuẩn mã hóa (chúng ta không có, nhưng tôi đang tìm cách tạo ra một tiêu chuẩn)?

Tuy nhiên, có nhiều công cụ và IDE khác nhau sẽ định dạng theo bất kỳ tiêu chuẩn nào mà lập trình viên thích.

Chúc may mắn với điều đó. Kinh nghiệm của tôi, có một số lượng nhỏ các công cụ (không!) Có thể định dạng lại mã chính xác từ định dạng X sang định dạng Y. Có quá nhiều thứ cản trở. Các tab so với dấu cách, các câu lệnh nhiều dòng, v.v. Chỉ cần nhìn vào việc triển khai các tệp thư viện chuẩn C ++ của GNU. Những gì bạn có thể làm là làm cho IDE của bạn làm là luôn luôn sử dụng khoảng trắng thay vì các tab và chỉ cần không định dạng lại mã nước ngoài. Bây giờ mã của bạn trông giống như bạn thích nó, và mã nước ngoài trông giống như cách tác giả ban đầu đã viết nó.

Một kiểu thụt đầu dòng cụ thể là điều cuối cùng mà một tiêu chuẩn mã hóa cần chỉ định. Đó là cố gắng bắt đầu một cuộc chiến tôn giáo lập trình. IMO, một tiêu chuẩn mã hóa nên chỉ định một bộ hợp lý các kiểu thụt đầu dòng có thể chấp nhận được, nhưng để lại các chi tiết cụ thể cho các tác giả của một gói. Phong cách thụt lề là, hoặc nên là một phần nhỏ của tiêu chuẩn mã hóa. Quy tắc số 0 của các tiêu chuẩn mã hóa: Đừng đổ mồ hôi cho những điều nhỏ nhặt. Phong cách thụt là một điều nhỏ.

Những điều lớn hơn:

• Làm thế nào để tôi đặt tên cho mọi thứ?
• Là một số phần của ngôn ngữ ra khỏi giới hạn?
• Mã có cần biên dịch sạch không, và với cài đặt trình biên dịch nào?
• Liệu mã phải vượt qua các số liệu nhất định?
• Những loại thử nghiệm là cần thiết?
• Những loại tài liệu là cần thiết, cả trong mã (ý kiến) và nơi khác?
• Quan trọng nhất, làm thế nào để tôi từ bỏ tiêu chuẩn?

Phụ lục
Có lẽ quan trọng hơn cả là những gì không được đưa vào một tiêu chuẩn mã hóa. Các chủ đề như làm thế nào để viết các yêu cầu không thuộc về các tiêu chuẩn mã hóa. Chi tiết về thử nghiệm cũng không thuộc về. Dự án không nên sử dụng các tiêu chuẩn mã hóa làm dự phòng cho kế hoạch quản lý dự án, kế hoạch quản lý kiểm tra, kế hoạch xác minh và xác nhận, v.v ... Mục tiêu của các tiêu chuẩn mã hóa là cải thiện an toàn mã, chất lượng, dễ hiểu, khả năng bảo trì, và "bất hợp pháp" khác. Có rất nhiều cách để đảm bảo rằng điều này sẽ không xảy ra. Chỉ một vài điều: Làm cho các tiêu chuẩn trở thành một cuốn sách phức tạp như luật thuế của một số quốc gia, kích động các cuộc chiến tranh tôn giáo, có các quy ước đặt tên xấu.

Tiêu chuẩn mã hóa có thể có những hậu quả không lường trước được. Ví dụ: Một số kẻ ngốc của một kỹ sư dự án sẽ diễn giải "quy tắc không có số ma thuật" có nghĩa là if (index == 0) {...}và for (ii = 0; ii < 3; ++ii) {...}phải được đổi thành if (ZERO == index) {}và for (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...}Đừng cười. Tôi đã thấy nó xảy ra. Ngày nay khi tôi viết một tiêu chuẩn mã hóa, đó là "hướng dẫn không có số ma thuật" hơn là một quy tắc để chống lại sự ngu ngốc này.

Tiêu chuẩn mã hóa không phải là biện pháp bảo vệ số một chống lại phong cách lập trình xấu / thực hành mã hóa nguy hiểm. Việc xem xét mã là. Mặc dù có nhiều năm tự động hóa, nhưng vẫn không có gì tốt hơn là có một đôi mắt chủ quan của con người nhìn vào và vượt qua sự phán xét về một đoạn mã.

Các tiêu chuẩn mã hóa không chỉ là về các tham số ưa thích cho indent- chúng còn bao gồm các quy ước đặt tên, quy ước bình luận và một số lượng lớn các khuyến nghị có thể có cho thành ngữ, sử dụng tính năng ngôn ngữ, v.v.

Hơn nữa, bạn vẫn cần ghi lại tất cả những điều này ở đâu đó. Và cuối cùng, không phải ai cũng muốn sử dụng một IDE định dạng lại mã theo cách đó ...

Nếu bạn sử dụng một kiểu nhất quán trong một nhóm, mã của bạn sẽ trở nên dễ đọc hơn. Khi mã của bạn trở nên dễ đọc hơn thì nhóm của bạn sẽ có năng suất cao hơn. Họ sẽ làm việc hiệu quả hơn vì họ không phải phân tích cú pháp về mặt tinh thần và có thể tập trung vào logic hơn là cú pháp khi xem xét và duy trì mã.

Nếu mỗi người cho phép IDE định dạng lại mã theo lựa chọn của họ, bạn có một trong hai vấn đề: hoặc bạn phải đảm bảo rằng bạn luôn chuyển đổi nó trở lại định dạng ban đầu khi lưu hoặc bị ảnh hưởng bởi sự khác biệt của bạn sẽ gây ra nhiều tiếng ồn, làm cho khó khăn hơn để xem những gì đã thay đổi trong logic của mã.

Câu trả lời ngắn: Có, nó phản ánh chất lượng .

Nó là gì và tại sao chúng ta cần nó?

Các tiêu chuẩn mã hóa là phần rất quan trọng của phần mềm chất lượng cao. Chúng làm tăng năng suất trong quá trình phát triển, làm cho mã dễ bảo trì hơn và giữ cho mã không bị ràng buộc với một người hoặc nhóm. Tính nhất quán trong tiêu chuẩn mã hóa cũng phân biệt mã được tạo sớm từ nghệ thuật được chế tạo tốt.

OK, mọi nhà phát triển đều biết rằng các quy ước mã hóa là tốt. Nhưng tiêu chuẩn nên đến từ đâu?

Nó chủ yếu được quyết định bởi nhà cung cấp sở hữu sản phẩm. Mỗi nhà phát triển có thể chọn từ nhiều tiêu chuẩn mã hóa công nghiệp. Một số công ty Microsoft, Oracle và Sun microsystems cung cấp hướng dẫn.

Có bất kỳ đối số nào cho sự phát triển của một tiêu chuẩn mã hóa (chúng ta không có, nhưng tôi đang tìm cách tạo ra một tiêu chuẩn)?

Có, có những tiêu chuẩn công nghiệp được khuyến nghị sử dụng. Tuy nhiên, mỗi tiêu chuẩn mã hóa là dành riêng cho nền tảng phát triển. Vì vậy, các tiêu chuẩn mã hóa chủ yếu là ngôn ngữ cụ thể. Ví dụ, Java có một tiêu chuẩn khác với .NET. Ví dụ C # .NET đang sử dụng các tiêu chuẩn đó trong tài liệu tham khảo này .

Tiêu chuẩn chung

Các tiêu chuẩn chung không có sự phụ thuộc vào bất kỳ ngôn ngữ lập trình nào. Ngoài các tiêu chuẩn được cung cấp bởi nhà cung cấp, còn gọi là các tiêu chuẩn mã hóa công nghiệp đã đề cập, còn có các ký hiệu lập trình khác nhau như Ký hiệu Hungary hoặc CamelCase . Tôi nghĩ rằng các tiêu chuẩn mã hóa Microsoft .NET ban đầu được dựa trên các ký hiệu CamelCase.

Nhóm tiêu chuẩn và hướng dẫn mã hóa

Trong suy nghĩ, mọi nhóm phát triển nên đồng ý về các tiêu chuẩn mã hóa ngay khi dự án bắt đầu. Các hướng dẫn mã hóa thường được tạo bởi Team Trưởng hoặc Kiến trúc sư trưởng của công ty. Nó thường là một tài liệu mở để được theo dõi và cải thiện theo nhu cầu. Ví dụ: trong công ty của chúng tôi, chúng tôi có các trang Wiki nơi tài liệu này được tải lên và có sẵn cho các nhà phát triển công ty.

Tôi sẽ đưa ra ý kiến ​​gây tranh cãi và nói không bạn không cần một tiêu chuẩn mã hóa . Như các quy tắc là, như bạn nói, các hướng dẫn có thể thi hành của IDE, các thực tiễn tốt nhất chung mà mọi người ở mọi công ty nên tuân theo, hoặc chúng là các cuộc gọi phán quyết theo từng trường hợp nên được thực hiện bởi nhiều người trong một nhóm có khả năng thông qua lập trình cặp hoặc đánh giá mã.

Những thứ như Làm thế nào chúng ta nên đặt tên biến này? Những tính năng ngôn ngữ nào chúng ta nên sử dụng? Có nên tránh? Thử nghiệm nào là tốt nhất? Đây là những điều tốt nhất chưa được trả lời cho đến khi chúng ta gặp phải vấn đề được xác định hẹp mà chúng ta đang làm việc ngay bây giờ .

Kết tinh từ các quyết định phút này, các tiêu chuẩn / mẫu không chính thức trong các nhóm có thể phát sinh, dựa trên giao điểm với miền vấn đề hiện tại và các công nghệ được sử dụng. Việc mã hóa những điều này có nghĩa là chúng tôi nghĩ rằng những thứ như tiêu chuẩn đặt tên, tập hợp ngôn ngữ phù hợp, v.v. được sử dụng cho các dự án này, dựa trên hàng trăm quyết định vi mô và được các nhóm này áp dụng một cách không chính thức sẽ hướng dẫn mọi dự án tiến lên.

Trong nguyên tắc nghe có vẻ như là một điều tuyệt vời, nhưng trong thực tế, nó chỉ trở thành một nam châm cho chính trị. Những công cụ nào chúng ta có thể buộc tất cả mọi người sử dụng? Tôi muốn ép buộc người khác tránh điều gì? Nếu mọi người đồng ý về những câu hỏi này, chúng tôi sẽ không cần một tiêu chuẩn. Chúng tôi sẽ làm điều đó. Theo kinh nghiệm của tôi, các tiêu chuẩn xuất phát từ mong muốn một tập hợp con của các nhà phát triển thực hiện quyền kiểm soát đối với tập hợp con khác. Điển hình là loại chính trị và chính sách công nghệ đi theo nó chỉ kìm hãm sự đổi mới thay vì đưa ra hướng dẫn.

Nếu bạn muốn được hướng dẫn thực sự , thay vì đọc một tiêu chuẩn với một loạt các quy tắc không có ích, hãy đi tìm các thành viên có khả năng trong nhóm của bạn và hỏi họ xem họ nghĩ gì. Họ đã bị đốt cháy bởi những gì? Làm thế nào để họ đề nghị bạn viết mã? Bạn sẽ nhận được nhiều câu trả lời hữu ích với nhiều kinh nghiệm quý giá để sao lưu nó. Bạn sẽ thấy rất nhiều giao lộ dựa trên kinh nghiệm chung. Thay vì độc canh được thi hành theo tiêu chuẩn, bạn cũng sẽ thấy rất nhiều sự đa dạng chỉ có thể giúp bạn thấy nhiều cách hợp lệ để giải quyết vấn đề.

Và khi ai đó bảo bạn không làm điều gì đó do nguyên tắc trong "tiêu chuẩn" nhưng không có kinh nghiệm hoặc sao lưu hợp lý cho khiếu nại của họ, hãy bỏ qua chúng. Ở đây, tiêu chuẩn đã không phục vụ bất cứ ai hoặc làm cho bất cứ ai trở thành một nhà phát triển tốt hơn.

Bây giờ máy bay thương mại đang hoạt động, bạn sẽ hy vọng các chương trình lái máy bay dựa trên các công việc đầu vào của phi công. Khi các lập trình viên viết mã như vậy, bạn hy vọng họ tuân theo một bộ quy tắc nghiêm ngặt để tránh các lỗi lập trình thường có thể tránh được. Một cách để làm điều này là với một tiêu chuẩn mã hóa.

Xem: Đề xuất tiêu chuẩn mã hóa C và C ++ của Cục quản lý hàng không liên bang

Cần tôi nói thêm.

Lưu ý: Tôi không thể tìm thấy tiêu chuẩn thực tế từ FAA trực tuyến, nhưng tôi đã thấy nó.

Đối với tôi, vấn đề kỷ luật và kỷ luật luôn có ích, nó phản ánh chất lượng công việc bạn sản xuất.

Phải nói rằng, tôi sẽ làm cho tiêu chuẩn mã hóa theo dõi IDE và / hoặc các công cụ được sử dụng. Hơn nữa, IDE phải được định cấu hình giống hệt nhau (ví dụ: mỗi IDE của nhà phát triển nên sử dụng tất cả các tab hoặc tất cả các khoảng trắng để thụt lề và IDE của mọi người nên có cùng độ dài tab) cho mỗi nhà phát triển để mọi người có thể dễ dàng tuân theo tiêu chuẩn ...

Ngoài ra, các kịch bản đăng ký có thể được phát triển và sử dụng, có thể giúp tuân thủ các tiêu chuẩn mã hóa ở một mức độ nhất định, ví dụ: chúng có thể sửa lỗi thụt đầu dòng trước khi thực sự đưa tệp đã kiểm tra vào hệ thống kiểm soát phiên bản.

Các tiêu chuẩn mã hóa KHÔNG thể quan trọng hơn nữa! Tôi là một người dùng CakePHP cuồng nhiệt và tôi muốn xem xét các thay đổi từ phiên bản này sang phiên bản khác và các nhà phát triển không tuân theo các tiêu chuẩn ở đó.

Trong thực tế, tôi đã rất buồn vì sự khác biệt trong phong cách mà tôi đã phải viết một đoạn ngắn về các quy ước mã hóa . Nó tốn rất nhiều thời gian và tiền bạc để đưa các nhà phát triển mới vào một nhóm hiện có - chỉ cần tưởng tượng việc đưa một nhà phát triển mới vào mà không có tiêu chuẩn ... việc học mã sẽ là điều không thể tiếp theo.