Tại sao chú Bob đề nghị rằng các tiêu chuẩn mã hóa không nên được viết ra nếu bạn có thể tránh nó?

Trong khi tôi đang đọc câu hỏi này , câu trả lời được bình chọn hàng đầu đã trích dẫn chú Bob về các tiêu chuẩn mã hóa , nhưng tôi đã bị nhầm lẫn bởi mẹo này:

3. Đừng viết chúng ra nếu bạn có thể tránh nó. Thay vào đó, hãy để mã là cách các tiêu chuẩn được nắm bắt.

Điều này nảy lên trong não tôi, nhưng tôi không thể tìm thấy một nơi nào để gắn bó. Nếu một người mới gia nhập nhóm, hoặc các tiêu chuẩn mã hóa thay đổi, không thể có sự nhầm lẫn về thông tin?

Tại sao tôi không nên viết ra một tiêu chuẩn mã hóa?

Có một vài lý do.

1. Không ai đọc tài liệu.
2. Không ai làm theo tài liệu ngay cả khi họ đọc nó.
3. Không ai cập nhật tài liệu ngay cả khi họ đọc nó và làm theo nó.
4. Viết một danh sách thực hành ít hiệu quả hơn nhiều so với việc tạo ra một nền văn hóa.

Các tiêu chuẩn mã hóa không phải là về những gì mọi người nên làm, mà là về những gì họ thực sự làm. Khi mọi người đi chệch khỏi các tiêu chuẩn, điều này nên được chọn và thay đổi thông qua quy trình xem xét mã và / hoặc các công cụ tự động.

Hãy nhớ rằng, toàn bộ quan điểm của các tiêu chuẩn mã hóa là làm cho cuộc sống của chúng ta dễ dàng hơn. Chúng là lối tắt cho bộ não của chúng ta để chúng ta có thể lọc ra những thứ cần thiết từ những thứ quan trọng. Tốt hơn hết là tạo ra một văn hóa đánh giá để thực thi điều này hơn là chính thức hóa nó trong một tài liệu.

Có một cách giải thích khác. Tôi không tin đó là ý của chú Bob, nhưng nó đáng để xem xét.

Đừng nắm bắt các tiêu chuẩn mã hóa trong một tài liệu. Nắm bắt nó trong mã, bằng cách có một quy trình tự động xác minh các tiêu chuẩn đang được đáp ứng .

Đừng dựa vào những người tham khảo tài liệu, nhưng đồng thời, đừng dựa vào những người diễn giải mã đã tồn tại và xác định quy ước và sự trùng hợp là gì.

Kết hợp một cái gì đó như Checkstyle vào bản dựng cam kết của bạn. Điều này có thể thực thi các quy tắc cơ bản như định dạng và đặt tên tiêu chuẩn, và sau đó thay vì nỗ lực tinh thần trong việc xem xét phong cách, tất cả có thể được giảm tải cho một quy trình ngu ngốc ít nhất được đảm bảo là triệt để.

Nếu nó quan trọng, thì hãy xác định chính xác những gì bạn muốn và thất bại nếu nó sai.

Mọi người bỏ qua mục đích thực sự của một tài liệu tiêu chuẩn mã hóa, đó là giải quyết tranh chấp .

Hầu hết các quyết định trong tiêu chuẩn mã hóa sẽ chỉ có ảnh hưởng rất nhỏ đến khả năng đọc và năng suất. Đặc biệt nếu bạn áp dụng phong cách 'bình thường' cho ngôn ngữ và các nhà thiết kế ngôn ngữ bắt đầu nhận ra rằng đây phải là một phần của thông số kỹ thuật (ví dụ: Go).

Bởi vì chúng quá tầm thường, các cuộc tranh luận có thể trở nên thực sự nóng lên và chạy vô tận, gây thiệt hại thực sự cho năng suất và sự gắn kết của đội. Hoặc có thể che khuất lịch sử thay đổi của bạn bằng cách định dạng lại vô tận giữa hai hoặc nhiều kiểu ưa thích của mọi người.

Có một tiêu chuẩn bằng văn bản kết thúc cuộc tranh luận. Các nhà quản lý có thể chỉ vào nó và làm chệch hướng sự không hài lòng đối với tài liệu. Bạn có thể tranh luận với một mảnh giấy nhưng nó sẽ không lắng nghe bạn.

(Xem thêm Sự chuyên chế của vô cấu trúc )

Vì ý kiến ​​là dối trá .

Tiêu chuẩn mã hóa là một nhận xét lớn tuyệt vời về những gì mã nên được. Bản thân mã là nguồn gốc của sự thật. Sự thật trong trường hợp này không phải là hành vi mã, đó là phong cách mà nó thể hiện. Nếu tiêu chuẩn của bạn chưa được phản ánh trong mã của bạn, bạn có rất nhiều công việc trước mắt.

Chú Bob thấy một bình luận là thất bại cá nhân của lập trình viên, bởi vì nó chứng tỏ rằng anh ta đã không quản lý để thể hiện mục đích của đoạn mã với chính ngôn ngữ lập trình. Tương tự, một tài liệu tiêu chuẩn là một sự thất bại trong việc thể hiện một phong cách mạch lạc trong cơ sở mã.

Các lập trình viên mới nên dành thời gian xem mã, không mất nhiều ngày để đọc tài liệu tiêu chuẩn nhiều chương (tôi phải làm điều này, thở dài).

Một tài liệu tiêu chuẩn không phải là một ý tưởng tồi, nhưng tôi đã ở trong các cửa hàng lập trình nơi việc duy trì các tài liệu tiêu chuẩn là công việc toàn thời gian của ai đó. Xin vui lòng, nếu bạn phải giữ một tài liệu tiêu chuẩn, hãy giữ nó ở một trang. Nhưng nếu bạn đã có mã, không ai có thể kết hợp cùng một tài liệu trong vòng chưa đầy một ngày?

Có tiêu chuẩn mã là quan trọng. Có một tài liệu chỉ ra những gì họ không phải là.

Tại sao chú Bob đề nghị rằng các tiêu chuẩn mã hóa không nên được viết ra nếu bạn có thể tránh nó?

Nếu bạn đang hỏi lý do đằng sau ý kiến ​​của anh ấy thì bạn chỉ có thể có câu trả lời nếu anh ấy sẽ đăng câu trả lời ở đây ( ý kiến của chúng tôi chỉ là không liên quan), tuy nhiên ...

Tại sao tôi không nên viết ra một Tiêu chuẩn mã hóa?

Nếu bạn hỏi liệu anh ấy có đúng về điều đó không: hãy để tôi là người duy nhất không phổ biến (cho đến nay) nói rằng bạn không có lý do gì để tránh điều đó.

VIẾT NÓ XUỐNG . Tuy nhiên tôi sẽ cố gắng giải thích lý do của mình ...

David đề nghị trong một bình luận rằng điểm chính của câu trả lời của Stephen không phải là lý do tại sao bạn không nên viết tài liệu mà ở dạng chúng. Nếu hướng dẫn được chính thức hóa trong các công cụ (không chỉ đơn thuần là xem xét mã thủ công) thì tôi có thể đồng ý (khi luật pháp không yêu cầu điều gì khác). Xin lưu ý rằng các công cụ không may không thể kiểm tra tất cả mọi thứ (lý thuyết tính toán không phải là bạn của chúng tôi) vì chúng bị giới hạn trong một đơn vị hoặc gói dịch cụ thể hoặc bất kỳ ngôn ngữ yêu thích nào của bạn gọi là ranh giới .

Tuy nhiên, cách diễn đạt của chú Bob không khiến tôi nghĩ rằng ông đang nói về điều đó.

Tôi có thể không đồng ý với chuyên gia cao cấp như vậy? Tôi làm, cho hầu hết mọi điểm trong bài viết được trích dẫn (xem thêm phần thứ hai của câu trả lời này để biết chi tiết). Chúng ta hãy cố gắng hiểu lý do tại sao (giả sử bạn đã biết rằng các nguyên tắc mã hóa không chỉ là về các vấn đề định dạng nhỏ ).

• Trong một số trường hợp, các tiêu chuẩn mã hóa được yêu cầu bởi luật pháp.
• Tôi đã đọc tài liệu và tôi chắc chắn rằng tôi không cô đơn. Các thành viên trong nhóm có thể thay đổi theo thời gian, kiến ​​thức không thể có trong một cơ sở mã 5-10 năm tuổi hoặc trong tâm trí của các thành viên trong nhóm. Các tổ chức nên sa thải những người không tuân theo các hướng dẫn nội bộ.
• Các tiêu chuẩn mã hóa, một khi chúng đã được phê duyệt , sẽ không thay đổi thường xuyên và nếu chúng muốn biết về nó. Nếu các tiêu chuẩn thay đổi thì tài liệu của bạn (trong mã) đã hết hạn vì tất cả mã của bạn không tuân theo tiêu chuẩn mới. Định dạng lại / tái cấu trúc có thể chậm nhưng bạn luôn có một hướng dẫn có thẩm quyền bằng văn bản để tuân theo.
• Tốt hơn là đọc một tài liệu 5 trang hơn là kiểm tra 10 / 20K LỘC để ngoại suy một quy tắc (mà bạn có thể hiểu sai, BTW), không nghi ngờ gì về điều đó.
• Thật trớ trêu khi ai đó đã viết nhiều cuốn sách về các nguyên tắc thiết kế và phong cách mã hóa đang gợi ý rằng bạn không nên viết hướng dẫn của riêng mình, sẽ không tốt hơn nếu anh ta bỏ rơi chúng tôi với một số ví dụ về mã? Không, bởi vì các hướng dẫn bằng văn bản không chỉ cho bạn biết phải làm gì mà còn hai điều khác mà mã thiếu: không nên làm gì và lý do để làm điều đó hay không.

"Lập trình tự tổ chức miễn phí" tốt cho một chàng trai 16 tuổi ninja nhưng các tổ chức có các yêu cầu khác :

• Chất lượng mã phải được cấp (và được xác định) ở cấp công ty - đó không phải là điều mà một nhóm duy nhất có thể quyết định. Họ thậm chí có thể không có kỹ năng để quyết định điều gì tốt hơn (ví dụ, có bao nhiêu nhà phát triển có tất cả các kỹ năng cần thiết để xem xét MISRA hoặc thậm chí chỉ hiểu mỗi quy tắc?)
• Các thành viên có thể được di chuyển qua các nhóm khác nhau: nếu mọi người tuân theo cùng một tiêu chuẩn mã hóa thì việc tích hợp diễn ra suôn sẻ và ít xảy ra lỗi hơn.
• Nếu một nhóm tự tổ chức thì các tiêu chuẩn sẽ phát triển theo thời gian khi các thành viên trong nhóm thay đổi - khi đó bạn sẽ có một cơ sở mã lớn không tuân theo các tiêu chuẩn được chấp nhận hiện tại .

Nếu bạn đang nghĩ về mọi người trước khi xử lý thì tôi chỉ có thể đề nghị đọc về TPS: con người là một phần trung tâm của Lean nhưng các thủ tục được chính thức hóa cao.

Tất nhiên một tổ chức nhỏ chỉ có một nhóm có thể để nhóm quyết định các tiêu chuẩn để áp dụng nhưng sau đó nó phải được viết ra. Ở đây trên Lập trình viên. Bạn có thể đọc các bài đăng của Eric Lippert: Tôi cho rằng tất cả chúng ta đều đồng ý rằng anh ta là một nhà phát triển có kinh nghiệm, khi làm việc cho Microsoft, anh ta phải tuân thủ các nguyên tắc bằng văn bản của họ (ngay cả khi một số quy tắc có thể sai , không áp dụng hoặc vô dụng với anh ta.) Còn Jon Skeet thì sao? Các nguyên tắc của Google khá nghiêm ngặt (và nhiều người không đồng ý với chúng) nhưng anh ta phải tuân thủ các nguyên tắc đó. Có phải là thiếu tôn trọng họ? Không, có lẽ họ đã làm việc để xác định và cải thiện các hướng dẫn như vậy, một công ty không được tạo bởi một thành viên (hoặc một nhóm) và mỗi nhóm không phải là một hòn đảo .

Ví dụ

• Bạn đã quyết định không sử dụng nhiều lớp kế thừa và các lớp lồng nhau trong C ++ vì các thành viên nhóm thực tế của bạn không hiểu rõ về nó . Sau này ai đó muốn sử dụng nhiều kế thừa phải duyệt toàn bộ LỘC 1M để xem nó đã từng được sử dụng chưa. Thật tệ vì nếu các quyết định thiết kế không được ghi nhận, bạn phải nghiên cứu toàn bộ cơ sở mã để hiểu chúng. Và thậm chí sau đó, nếu nó chưa được sử dụng, có phải vì nó trái với tiêu chuẩn mã hóa, hay nó được cho phép, nhưng không có bất kỳ tình huống nào trước đó mà nhiều sự thừa kế là phù hợp?
• Trong C #, bạn đã quá tải các phương thức để cung cấp các tham số mặc định vì cơ sở mã của bạn bắt đầu khi các tham số tùy chọn không có sẵn trong C #. Sau đó, bạn thay đổi và bạn bắt đầu sử dụng chúng (tái cấu trúc mã cũ để sử dụng chúng mỗi khi bạn phải sửa đổi các chức năng đó). Thậm chí sau đó bạn đã quyết định rằng các tham số tùy chọn là xấu và bạn bắt đầu tránh sử dụng chúng. Là gì quy tắc mã của bạn sẽ cho bạn biết? Thật tệ vì tiêu chuẩn phát triển nhưng codebase phát triển chậm hơn và nếu đó là tài liệu của bạn thì bạn sẽ gặp rắc rối.
• Jon chuyển từ đội A sang đội B. Jon phải học một tiêu chuẩn mới; Trong khi học, anh ta có thể sẽ giới thiệu các lỗi tinh vi hơn (hoặc, nếu may mắn, chỉ mất một thời gian dài để hiểu mã hiện có và làm cho mã xem lại lâu hơn).
• Đội A chuyển sang một cơ sở mã được sở hữu trước đây bởi đội B. Nó có các tiêu chuẩn mã hóa hoàn toàn khác nhau. Viết lại? Phỏng theo? Pha trộn? Tất cả đều tệ như nhau.

Chú Bob

Hãy để chúng phát triển trong vài lần lặp đầu tiên.

Đúng, cho đến khi bạn không có một tiêu chuẩn và tổ chức của bạn đã giao cho bạn nhiệm vụ xây dựng một tiêu chuẩn .

Hãy để họ là nhóm cụ thể thay vì công ty cụ thể.

Không, vì tất cả các lý do đã giải thích ở trên. Ngay cả khi bạn nghĩ để chính thức hóa định dạng mã (điều ít hữu ích nhất bạn có thể muốn chính thức hóa) tôi vẫn có ký ức về những cuộc chiến vô tận (và vô dụng) về định dạng. Tôi không muốn sống chúng nhiều lần, hãy đặt nó một lần cho tất cả.

Đừng viết chúng ra nếu bạn có thể tránh nó. Thay vào đó, hãy để mã là cách các tiêu chuẩn được nắm bắt.

Không, vì tất cả các lý do đã giải thích ở trên (tất nhiên trừ khi bạn sẽ cấu trúc lại tất cả mã của mình trong một lần khi hướng dẫn thay đổi). Bạn có muốn để lại mã như hiện tại không? Làm thế nào để bạn kiểm tra codebase để hiểu các hướng dẫn hiện tại ? Tìm kiếm theo tuổi tệp và điều chỉnh kiểu mã hóa của bạn theo tuổi tệp nguồn?

Đừng quy định thiết kế tốt. (ví dụ: đừng nói với mọi người không sử dụng goto)

Đúng, hướng dẫn phải ngắn gọn hoặc không ai sẽ đọc chúng. Đừng lặp lại điều hiển nhiên.

Hãy chắc chắn rằng mọi người đều biết rằng tiêu chuẩn là về giao tiếp, và không có gì khác.

Không chỉ, một tiêu chuẩn tốt là về chất lượng trừ khi bạn muốn có một tiêu chuẩn chỉ về các chi tiết nhỏ .

Sau vài lần lặp đầu tiên, hãy cùng nhóm quyết định.

Xem điểm đầu tiên và đừng quên rằng một tiêu chuẩn mã hóa thường là một quá trình mất nhiều năm để được phát triển và hoàn thiện: vài lần lặp lại, có thể với các nhà phát triển cơ sở? Có thật không? Bạn có muốn dựa vào trí nhớ của một thành viên cao cấp (nếu có) không?

Ba lưu ý:

• Theo tôi, nhược điểm là nghiêm trọng hơn với một số ngôn ngữ so với các ngôn ngữ khác, ví dụ như trong C ++, một tiêu chuẩn cấp công ty thậm chí còn cần thiết hơn so với Java.
• Lý do này có thể không áp dụng hoàn toàn (và lý do của chú Bob có thể ít cực đoan hơn ) nếu bạn làm việc trong một công ty rất nhỏ nơi bạn chỉ có một nhóm nhỏ.
• Bạn được tuyển dụng (theo nhóm) và bạn sẽ làm việc một mình với một dự án mới, sau đó bạn sẽ quên nó và tiếp tục. Trong trường hợp này, bạn có thể không quan tâm (nhưng chủ nhân của bạn nên ...)

1. Để có ích, một tiêu chuẩn mã hóa không được nói về các vấn đề thực chất; Chỉ vấn đề về phong cách. Nó chỉ nên chỉ định những điều đó là tùy tiện và mơ hồ. ví dụ: vị trí Brace, độ sâu thụt, khoảng trắng so với tab, quy ước đặt tên, v.v.
2. Các vấn đề về phong cách là địa phương, không phải toàn cầu. Mỗi đội nên áp dụng phong cách đặc biệt của riêng mình, phù hợp với nhiệm vụ và tính cách của họ. Điều này giữ cho các tiêu chuẩn đơn giản và trọng lượng nhẹ. Các tiêu chuẩn của công ty trở nên quá tải với tất cả các cân nhắc, cấu hình và ngoại lệ có thể.
3. Trong một nhóm, lý do duy nhất để viết một tài liệu kiểu mã hóa riêng là nếu mã do nhóm tạo ra không đáp ứng tiêu chuẩn. Trong trường hợp bạn không có tiêu chuẩn. Để có hiệu lực, tiêu chuẩn phải được thể hiện bằng chính mã. Và nếu đó là như vậy, không cần một tài liệu riêng.
4. Trong các hệ thống kế thừa đội và phong cách thay đổi theo thời gian. Không có gì sai với điều đó. Mã cũ sẽ có kiểu cũ. Mã mới hơn sẽ có phong cách mới hơn. Nhóm nên nhận thức được các phong cách, và tuổi của họ. Bất cứ khi nào mã mới được viết, nó phải theo phong cách mới, bất kể nó nằm ở đâu trong mã.

Tại sao tôi không nên viết ra một Tiêu chuẩn mã hóa?

Có nhiều lý do cho việc này. Dưới đây là một số cân nhắc:

1. Mọi người dành bao nhiêu thời gian để "học" các tiêu chuẩn mã chỉ để có nhiều thời gian đi vào toàn bộ nhóm xem xét, thảo luận, ghi chép, sửa đổi ... vv các tiêu chuẩn mã. Điều này giống như liên tục thảo luận về "Sổ tay nhân viên" của bạn - mức độ thường xuyên làm cho nó trong chương trình họp của nhóm?

2. Khi một dự án bị ô nhiễm / gác lại / vv. sau đó một số ít người thường không thể tiếp tục tuân thủ (hoặc thậm chí có thể không đọc) các tiêu chuẩn. Điều tiếp theo bạn biết, tất cả những nỗ lực để "giữ mã sạch" dù sao cũng đã bị lãng phí khá nhiều.

3. Nếu quầy hàng của dự án hoặc một khách hàng tiềm năng mới được đưa vào, rất có thể người đó sẽ hoàn toàn bỏ qua các quy tắc trước đó và muốn thực hiện theo cách mới. Một lần nữa, những gì đã đạt được bằng cách mã hóa các tiêu chuẩn ??

Bạn nên chắc chắn đọc # 6:

Sau vài lần lặp đầu tiên, hãy cùng nhóm quyết định.

Nói cách khác, khi đến lúc bắt đầu một dự án, chỉ cần đi theo dòng chảy một lúc. Sau đó thảo luận về các quy tắc chung về tiêu chuẩn mã hóa mà nhóm hiện tại đang sử dụng - và về cơ bản tuân theo chúng. Bằng cách đó, bạn tối đa hóa nỗ lực cải thiện sản phẩm đồng thời giảm thiểu nỗ lực cần thiết để viết, xem xét và ghi lại "đường cú pháp" để có được mã thực thi.

Rất ít đội có được lợi ích lớn từ các tiêu chuẩn mã hóa. Thông thường, "khả năng đọc" quá mơ hồ - và hầu hết các nhà phát triển không được hưởng lợi nhiều từ các quy tắc chính xác về khoảng cách, dòng mới, v.v. nhưng bạn có thể tránh các nhà phát triển liên tục gây phiền nhiễu bằng cách có ít nhất một vài quy tắc.

Một câu trả lời khác mà tôi không nghĩ đã được nêu rõ ràng, đó là nó cũng có nghĩa là mọi người không tuân theo các quy tắc một cách mù quáng. Điều đó có nghĩa là mọi người phải đưa ra những biện minh thực tế cho các quyết định thiết kế và quy ước mã hóa của họ, thay vì chỉ phụ thuộc vào thực tế rằng nó đã được viết ra để biện minh cho nó.

Thứ nhất, theo như tôi biết, chú Bob là một người Java, điều này rất quan trọng để hiểu những gì ông nói.

Khi làm việc trong nhóm Java hoặc C #, nếu mã hiện tại đã được viết bởi các nhà phát triển có kinh nghiệm, tôi sẽ dễ dàng chọn phong cách mã hóa và theo kịp nó. Nếu tôi không sẵn lòng làm điều đó, có lẽ tôi không phải là người phù hợp với công việc ... Nếu không có đánh giá mã hoặc lập trình cặp để đón tôi khi tôi không giữ đúng phong cách, thì công ty có vấn đề lớn hơn so với cách tôi đặt tên các lĩnh vực thành viên!

Cả Java và C #, cùng với hầu hết các ngôn ngữ hiện đại, đã được xác định để có một số bẫy "đơn giản" để lập trình viên rơi vào.

Tuy nhiên khi tôi bắt đầu lập trình tôi đang sử dụng C (và sau này là C ++). Trong C bạn có thể viết mã như

if (a = 3);
{
   /* spend a long time debugging this */
}

Trình biên dịch sẽ không đưa ra lỗi và rất khó phát hiện khi đọc nhiều mã. Tuy nhiên, nếu bạn viết:

if (3 = a)
{
   /* looks odd, but makes sense */
}

Trình biên dịch đưa ra một lỗi và tôi dễ dàng thay đổi mã thành 3 == a. Tương tự, nếu tiêu chuẩn mã hóa không cho phép =được sử dụng trong một ifđiều kiện hoặc " ifcâu lệnh trống ", thì trình kiểm tra mã có thể được sử dụng như một phần của hệ thống xây dựng để theo dõi lỗi này.

Quan điểm của tôi về các tiêu chuẩn mã hóa đã thay đổi rất nhiều khi tôi rời khỏi C / C ++: Tôi đã từng thích các tiêu chuẩn mã hóa được thi hành nghiêm ngặt và dài nhiều trang. Bây giờ tôi nghĩ rằng bạn chỉ cần liệt kê các công cụ đang được sử dụng và có được thỏa thuận không chính thức giữa các thành viên trong nhóm ban đầu về một vài quy ước đặt tên. Chúng tôi không còn sống trong một thế giới gồm hơn 30 nhà phát triển viết ứng dụng bằng C / C ++ ...

Có một lý do tôi không bao giờ thích JScript và nghĩ rằng TypeScript là điều tốt nhất sẽ xảy ra để phát triển web trong nhiều năm. Tôi hy vọng rằng các nhà phát triển giao diện người dùng web vẫn cần các tiêu chuẩn mã hóa do các khiếm khuyết trong thiết kế HTML / CSS / JScript, v.v.

Có nguồn là tiêu chuẩn mã hóa tài liệu tự ngụ ý hai điều.

1. Mọi người phải tham khảo cơ sở mã và xem xét nó để trở thành người đóng góp thành thạo. Điều này là vô cùng quan trọng. Đọc hướng dẫn mã hóa là một sự lãng phí thời gian so với việc đi sâu vào cơ sở mã.
2. Nó thừa nhận rằng sự khác biệt nhỏ là không quan trọng. Điều quan trọng là phải đồng ý và hiểu các nguyên tắc cơ bản. Duy trì một phong cách nhất quán không được theo đuổi vì tôi sẽ đổ. Nó không cho phép những kẻ lừa đảo không sáng tạo làm phiền và đánh lạc hướng người khác. Đó là về việc tạo điều kiện giao tiếp thông qua mã trong một nhóm.

Một tài liệu tiêu chuẩn mã được cập nhật thường xuyên và được viết tốt có thể rất hữu ích, nhưng thường thì đây không phải là trường hợp. Tài liệu tiêu chuẩn không phản ánh các tiêu chuẩn mã hóa thực tế được sử dụng bởi công ty vì rất khó để tạo ra một tài liệu tiêu chuẩn tốt và thậm chí còn khó khăn hơn để giữ cho nó cập nhật.

Thay vì có một tài liệu tiêu chuẩn mã hóa kém và sai lệch, tốt hơn là không có và để cho chính mã đại diện cho các tiêu chuẩn đó. Dù bằng cách nào, phần quan trọng nhất là áp dụng các tiêu chuẩn trong mã và điều này đòi hỏi nhiều hơn là một tài liệu. Động lực, quy trình, đào tạo, công cụ, vv là quan trọng hơn nhiều.

Một điều rất quan trọng chưa được nêu rõ ràng là các tiêu chuẩn mã hóa giống như ngôn ngữ: chúng phát triển. Một tiêu chuẩn mã hóa bằng văn bản cản trở điều này, và nếu nó không liên tục lỗi thời và vô dụng.

Không có một tiêu chuẩn mã hóa đóng đinh không phải là xấu. Nếu bạn thực hiện đánh giá ngang hàng khi đăng ký, bất cứ khi nào điều gì đó không tuân thủ tiêu chuẩn mã hóa đi vào kho lưu trữ có nghĩa là 2 người nghĩ về nó * và quyết định lợi ích của biến thể này lớn hơn sự không nhất quán với phần còn lại của mã.

Không có một tiêu chuẩn được viết ra cũng loại bỏ băng đỏ sẽ ngăn một nhóm công ty thử một biến thể mới của tiêu chuẩn mã hóa cho một dự án mới, vì họ muốn thử một cái gì đó, hoặc có thể vì một tiêu chuẩn khác có các ứng dụng thực tế trên một số công cụ tự động họ sử dụng.

Viết ra một tiêu chuẩn có xu hướng loại bỏ tính linh hoạt hơn so với dự định ban đầu, trong khi cũng chiếm khá nhiều thời gian có thể được dành để làm những việc khác. Tôi không nói rằng bạn không nên viết tiêu chuẩn mã hóa, các tiêu chuẩn bằng văn bản chắc chắn có lợi ích của chúng, đặc biệt nếu các nhóm làm việc ở các vị trí khác nhau làm việc trên cùng một cơ sở mã.

Liên quan chặt chẽ: Sự phát triển trong các tiêu chuẩn mã hóa, làm thế nào để bạn đối phó với chúng?

* Nếu mọi người không nghĩ trong khi xem xét mã ngang hàng khi đăng ký, vấn đề của bạn lớn hơn nhiều so với chỉ tiêu chuẩn mã hóa.

Thay đổi chúng trở thành một trở ngại lớn, và mọi người sẽ tuân thủ một cách an toàn thư pháp luật thay vì tham gia vào bộ não và làm điều đúng đắn.

Sẽ đến một ngày khi một phần của tiêu chuẩn không có ích, và làm cho mã trở nên tồi tệ hơn. Một số người sẽ tuân thủ tiêu chuẩn, bởi vì nó được viết ra và chúng an toàn, và bởi vì các quy tắc phải được tuân theo. Những người muốn viết mã tốt hơn là mã tuân thủ tiêu chuẩn sẽ thất vọng và tức giận. Sẽ có những tranh luận và bất đồng, trong khi nếu tiêu chuẩn không được viết ra, sẽ có sự thăm dò và thảo luận.

Tôi nghĩ rằng nhiều bài viết ở đây là nhầm lẫn tiêu chuẩn mã hóa với hướng dẫn phong cách .

Đảm bảo rằng các mô-đun được phát triển bởi các nhóm khác nhau có cùng tùy chọn trình biên dịch và ABI là một loại khác với số lượng khoảng trống được thụt lề.

Những thứ như cách thích hợp để cấu trúc các tệp #incoide và không gây ô nhiễm không gian tên toàn cầu trong tệp tiêu đề phải được ghi lại để chúng có thể được sử dụng làm danh sách kiểm tra trong quá trình đánh giá mã và mã ban đầu.

Cụ thể là "không sử dụng XXX vì nó gây ra sự cố tương thích với YYY" không phải là thứ bạn sẽ thấy bằng ví dụ khi theo mã khác, vì nó không có ở đó. Vì vậy, hãy để mã là cách các tiêu chuẩn được nắm bắt có thể không rõ ràng hoặc thiếu hoàn toàn đối với một số loại tiêu chuẩn, và do đó đây không thể là một kế hoạch phổ quát.

Một cái gì đó có sức lan tỏa nghiêm trọng và quan trọng như không sử dụng ngoại lệ hoặc không sử dụng newtrong một số hệ thống nhúng nhất định có thể chỉ đơn giản là kiến ​​thức văn hóa chung, vì "thông tin là văn hóa (chỉ)" mâu thuẫn với các nguyên tắc cơ bản của tiêu chuẩn sản xuất như ISO-9000, rằng nhà phát triển các hệ thống nhúng này đang sử dụng (ví dụ cho các ứng dụng ô tô). Những điều quan trọng này phải được ghi lại, ký tắt và nộp đi một cách chính thức.

Nhưng điều đó áp dụng cho mã hóa , không phải cho phong cách .

Các nhà phát minh của C và C ++ cho thấy, ví dụ, việc sử dụng tên viết thường và không phải CaMelCaSe. Vậy tại sao nhiều nhà phát triển không làm theo ví dụ ngầm từ fount? Không phải phong cách của thư viện tiêu chuẩn và các tài liệu giảng dạy kinh điển có phải là phong cách ngầm để tuân theo không?

Trong khi đó, mọi người làm theo ví dụ về các tiêu đề thư viện tiêu chuẩn cho những thứ không nên sao chép, như việc sử dụng __Uglytên cho các tham số macro và mẫu không lặp lại của tệp bao gồm.

Vì vậy, có những thứ thường không được xem là phong cách quan trọng, hoặc ngược lại có những ví dụ có thể không rõ ràng về những gì không nên tuân theo trong mã dự án. Cả hai đều là ví dụ cho luận điểm rằng "phong cách" (hay quy ước mã hóa) là tốt nhất để lại ẩn.