Đội của tôi có nên sử dụng một số tiêu chuẩn mã hóa phổ biến được coi là cơ sở cho chính nó không?


9

Nhóm R & D mà tôi tham gia đã quyết định áp dụng một tiêu chuẩn mã hóa. Chúng tôi chỉ mới thành lập gần đây và có quá ít mã và thời gian mã hóa chung để dựa trên tài liệu tiêu chuẩn / quy ước của chúng tôi về những gì đã phát triển hữu cơ trong nhóm của chúng tôi và trên các ví dụ hay từ mã của chúng tôi, v.v.

Bây giờ, mỗi người trong chúng ta đều có một số kinh nghiệm từ nơi làm việc trong quá khứ - mặc dù không ai trong chúng ta ở trạng thái nói rằng "hãy áp dụng tài liệu toàn diện này ở đây mà tôi thấy phù hợp với loại công việc chúng ta làm ở đây" (*). Thêm vào đó, một số người trong chúng tôi (bao gồm cả bản thân tôi) chỉ có kinh nghiệm từ những nơi không có tiêu chuẩn mã hóa chính thức hoặc viết bằng các ngôn ngữ khác nhau trong một môi trường khác (môi trường sản xuất phát hành hàng tuần áp lực cao, trái ngược với công việc phát triển theo định hướng nghiên cứu hơn)

Vì vậy, một trong những lựa chọn tôi đã nghĩ đến là lấy một tài liệu tương đối nổi tiếng và được đánh giá cao, loại bỏ những gì chúng ta không quan tâm / quan tâm và thực hiện một số sửa đổi dựa trên sở thích của chúng tôi.

Đây có phải là một thực tế phổ biến? Bạn có tin rằng đây là một ý tưởng tốt? Nếu vậy, điều gì sẽ là một tiêu chuẩn mã hóa 'cơ bản' hợp lý (đừng nói với tôi điều gì là tốt nhất, tôi không muốn bắt đầu một cuộc xung đột tôn giáo ở đây; chỉ cần chỉ ra điều gì sẽ toàn diện hoặc 'trung lập' để xây dựng .)

Ghi chú:

  • Chúng tôi hy vọng sẽ làm việc với C, C ++, OpenCL, CUDA, Python.
  • Chúng tôi là một nhóm gồm 4 người + người quản lý, dự kiến ​​sẽ tăng lên khoảng 5-6 trong vòng một năm hoặc lâu hơn.
  • Trong công ty của chúng tôi, các nhóm gần như hoàn toàn tự chủ và thường không tương tác với nhau (thậm chí không sử dụng mã của nhau - công việc thuộc các dự án hoàn toàn khác nhau); vì vậy - không có cân nhắc trên toàn công ty để thực hiện.
  • Về các công cụ, hiện tại những gì chúng ta biết là chúng ta sẽ sử dụng Eclipse , do đó, trình định dạng mã của nó sẽ trở thành một công cụ ít nhất. Ctrl + Shift + F từ lâu đã là bạn của tôi
  • Khi tôi viết Java, tôi đã áp dụng cách tuân thủ nghiêm ngặt nhất có thể với Java hiệu quả của Bloch . Bây giờ, đó không hoàn toàn là một tiêu chuẩn mã hóa, nhưng bạn có thể gọi một số viên gạch, xi măng và vữa cho một tiêu chuẩn mã hóa. Tôi đã nghĩ về việc có thể bao gồm một cái gì đó giống như là một phần của 'hỗn hợp' (lưu ý rằng chúng ta không làm Java).
  • Ý tôi là các tiêu chuẩn mã hóa theo nghĩa rộng hơn của từ này, ví dụ như chấp nhận các đề xuất được đưa ra trong các câu trả lời cho câu hỏi P.SE này .
  • Tôi đã tìm thấy một danh sách lớn các tài liệu tiêu chuẩn mã hóa C ++ ; có lẽ tôi nên khai thác cơ sở của chúng tôi
  • (*) Điều đó không hoàn toàn đúng, nhưng tôi không muốn làm phức tạp câu hỏi này với quá nhiều chi tiết cụ thể.

9
Sử dụng một tiêu chuẩn mã hóa được tạo ra bên ngoài giúp giảm các cuộc chiến thần thánh về các kiểu mã hóa cụ thể.
Gort Robot

4
Có gì chủ trương bạn sử dụng không thực sự quan trọng. Vấn đề là bạn sử dụng một cáimọi người đều đồng ý sử dụng như nhau . Đó là phần cuối cùng dễ thực hiện hơn nếu bạn chọn một cách lành mạnh.
Joachim Sauer

3
Quy ước đặt tên được đánh giá cao. Nếu bạn có một mô-đun nơi các chức năng là CamelCase và một mô-đun khác là rắn_case, thì đó không phải là vấn đề lớn nếu bạn đồng ý tuân theo quy ước đã có sẵn cho từng thành phần. Vì vậy, nếu cuộc chiến thần thánh trở nên quá nóng, chỉ cần dừng nó lại và để nó không nhất quán.
Jan Hudec

1
Tôi có rất ít kinh nghiệm về Eclipse, nhưng người thi hành tiêu chuẩn Mã (không phải kiểu) cho Eclipse có thể hữu ích
Dan Pichelman

1
Vì vậy, sự lựa chọn của bạn là sử dụng một tiêu chuẩn hiện có hoặc dành thời gian và tiền bạc để tạo ra một tiêu chuẩn? Tôi không thấy sự lựa chọn nào ở đây. Đi với tùy chọn miễn phí.
Ramhound

Câu trả lời:


9

Nói cách khác, bạn đang hỏi liệu bạn có nên bắt đầu các tiêu chuẩn mã hóa của nhóm của mình hay không bằng cách mượn các tiêu chuẩn bên ngoài mà bạn đã tìm thấy. Có vẻ như không ai trong nhóm có ý kiến ​​siêu mạnh (chưa) về những tiêu chuẩn đó phải là gì.

Một cách dứt khoát, câu trả lời là có.

Một tiêu chuẩn có nguồn gốc bên ngoài là vượt trội so với không có gì. Nhìn vào các câu trả lời trong " https://softwareengineering.stackexchange.com/q/84203/53019 " để thấy một số lợi thế để có một tiêu chuẩn. Tính nhất quán và có cơ sở để thay đổi từ quan trọng là quan điểm của bạn.

Ngoài ra, hãy xem " Xử lý các tiêu chuẩn mã hóa tại nơi làm việc (tôi không phải là ông chủ) " vì nó đi vào một số động lực nhóm mà nhóm của bạn cần xem xét khi chọn (các) tiêu chuẩn nên là gì. Nhóm cần sở hữu (các) tiêu chuẩn mã hóa của mình để mọi người sẵn sàng tuân thủ các hạn chế mà họ đặt ra đối với cách mỗi người viết mã.

Bạn đã liên kết với câu hỏi này, nhưng nó đáng để chỉ ra câu trả lời hàng đầu và tập trung vào việc hiểu lý do tại sao các yêu cầu được đưa ra. Nếu bạn sử dụng một tiêu chuẩn bên ngoài, nhóm của bạn sẽ khó hiểu được cơ sở đằng sau tất cả các yêu cầu đó. Nhưng nếu bạn chấp nhận rằng họ ở đó chỉ đơn giản vì nhóm của bạn cần một thứ gì đó để bắt đầu, thì thật dễ dàng để chuyển sang thay đổi tiêu chuẩn bên ngoài đó thành thứ gì đó phù hợp hơn với nhóm của bạn.

Có bất kỳ tiêu chuẩn nào cho phép bạn đưa ra các quy tắc định dạng bạn sẽ sử dụng với IDE của mình (Eclipse trong trường hợp của bạn). " Ưu điểm và nhược điểm của cải cách mã cưỡng bức " mang lại lợi ích cho mọi người trong nhóm vì có sự thống nhất với mã họ đang làm việc và cung cấp cho bạn khả năng định dạng lại đoạn trích bạn có thể mượn từ các dự án khác. Một phần thưởng bổ sung của việc sử dụng một tiêu chuẩn bên ngoài là nó có thể đã được điền trước trong phần định dạng mã của IDE của bạn.

Ai đó trong nhóm có thể sẽ phàn nàn về một phần cụ thể của tiêu chuẩn và sẽ đổ lỗi cho việc bạn sử dụng một tiêu chuẩn bên ngoài làm cơ sở. Có họ đọc qua:
- Tôi ghét một trong những tiêu chuẩn mã hóa của chúng tôi và nó khiến tôi phát điên, làm thế nào để xử lý nó?
- Làm thế nào để bạn vượt qua sự thiên vị mã hóa của riêng bạn khi trao mã kế thừa?
và sau đó nhận ra rằng họ có thể đã phàn nàn về một cái gì đó trong tiêu chuẩn cho dù nó đến từ đâu. Trên khắp số lượng đội tôi đã làm việc, tôi vẫn chưa thấy một tiêu chuẩn mà mọi người a) phổ biến và b) đồng ý với mọi phần của tiêu chuẩn. Tham khảo lại một số liên kết ban đầu để xem làm thế nào để đối phó với những mối quan tâm đó.


Phụ lục, bạn đã hỏi về "cái nào" bạn nên sử dụng. Tôi đặc biệt sẽ không trả lời rằng vì bất kỳ câu trả lời nào cũng có khả năng gây hoang mang với ý kiến ​​thúc đẩy các cuộc chiến ngọn lửa. Tuy nhiên, bạn có thể nhìn vào IDE (Eclipse) của bạn và xem những tùy chọn nào nó cung cấp như cấu hình tiêu chuẩn. Tôi cũng sẽ tìm kiếm một chút và xem có dự án nào bổ sung vào IDE của bạn không và cung cấp các tùy chọn tiêu chuẩn bổ sung để chọn. Dù đúng hay sai, những tiêu chuẩn đó đã được áp dụng cho bạn và có thể tiết kiệm cho nhóm của bạn một khối công việc trong việc định cấu hình cho mọi người.


6

Tôi sẽ bắt đầu với python. Python có các hướng dẫn mã hóa mà hầu hết mọi lập trình viên python ngoài kia đều tuân theo. Chúng là một phần của tài liệu chính thức được gọi là PEP8 .

C / C ++ là một mớ hỗn độn lớn vì những lý do lịch sử, nhưng vì python thì không, tôi khuyên bạn nên tuân theo quy ước đặt tên python trong C / C ++ vì sự thống nhất.

Bây giờ đối với C ++, điều thực sự quan trọng hơn là phải đồng ý với các thành ngữ phổ biến và đảm bảo rằng mọi người đều hiểu phong cách C ++ hiện đại hợp lý hơn bất kỳ cuộc chiến nào về quy ước đặt tên. Bạn nên bắt đầu với Tiêu chuẩn mã hóa C ++ và từ các tài nguyên trực tuyến, đảm bảo đọc Câu hỏi thường gặp về C ++ .


Trên thực tế, tôi tin rằng chúng ta sẽ có các quy ước đặt tên khác nhau cho mỗi C, C ++ và Python - ít nhất, những thứ được viết như viết hoa, sử dụng dấu gạch dưới, v.v ... MyTypeNameđược cho là tốt hơn C ++ my_type_name_t, và ngược lại là C. các tài liệu tham khảo.
einpoklum

Đối với C ++, bạn có thể sử dụng tiêu chuẩn được sử dụng bởi STL và boost. Không phải ai cũng thích nó nhưng vì bạn chắc chắn sẽ sử dụng một số thùng chứa stl nên nó sẽ phù hợp với điều đó.
Laurent Bourgault-Roy

@einpoklum: Đối với tất cả các loại thư viện chuẩn C, C ++ và Python không sử dụng "Snake_case"; không có sự khác biệt ở đó Sự khác biệt duy nhất là bạn muốn sử dụng "Hỗn hợp" cho các loại hay "rắn_case". Thư viện C và C ++ sử dụng "Snake_case", nhưng nếu không thì "MixedCase" là rất phổ biến.
Jan Hudec

@einpoklum Sử dụng bộ chuẩn của thư viện chuẩn cho C ++.
Miles Rout

3

Bạn thậm chí không thể thảo luận về chủ đề này mà không phân biệt giữa tiêu chuẩn mã hóatiêu chuẩn phong cách mã hóa .

Tiêu chuẩn mã hóa là một tập hợp các quy tắc xác định cơ chế ngôn ngữ nào bạn được phép sử dụng, cơ chế ngôn ngữ nào bạn không được phép sử dụng và cách sử dụng chúng. Nói cách khác, bạn xác định một tập hợp con của ngôn ngữ được sử dụng và / hoặc siêu bộ, nếu tiêu chuẩn mã hóa xử lý một số phần mở rộng không chuẩn.

Một tiêu chuẩn phong cách mã hóa chỉ liên quan đến các vấn đề thẩm mỹ: nơi đặt dấu ngoặc và dấu cách, cách đặt tên định danh, cách đặt nhận xét, v.v.

Hai điều khác nhau có thể nằm trong cùng một tài liệu. Tuy nhiên, nghiêm trọng nhất trong các tiêu chuẩn mã hóa không liên quan đến phong cách - những tiêu chuẩn tôi khuyên dưới đây thì không. Nhiều khả năng vì phong cách mã hóa rất chủ quan và do đó gây ra nhiều xích mích khi ý kiến ​​va chạm.

Đối với C / C ++, các tiêu chuẩn mã hóa có danh tiếng tốt nhất là của MISRA . Chúng được thiết kế chính cho các ứng dụng quan trọng / an toàn, nhưng vì chìa khóa để làm cho các chương trình an toàn hơn là loại bỏ và tránh các lỗi, các tiêu chuẩn MISRA áp dụng cho bất kỳ nhánh lập trình nào mà lỗi không mong muốn.

Các tiêu chuẩn từ CERT cũng khá nổi tiếng và thiên về lập trình máy tính để bàn và bảo mật phần mềm (hơn là an toàn). CERT có các tiêu chuẩn cho C, C ++, Java và Perl và các tiêu chuẩn này là miễn phí.

Tôi sẽ bắt đầu bằng cách xem xét MISRA và CERT, thay vì một số tiêu chuẩn nhà để xe ngẫu nhiên được tìm thấy trên web.


1
Tôi chưa bao giờ nghe về MISRA trước đây và tôi không thấy rằng các thành phần của nó là những người chơi quá quan trọng. Bạn có thể giải thích danh tiếng của họ? Đối với các tài liệu CERT, bạn có thể làm rõ liệu đây là các tiêu chuẩn cho các chương trình bảo mật cụ thể hay các tiêu chuẩn chung hơn không?
einpoklum

@einpoklum Để bắt đầu, MISRA-C được sử dụng bởi khá nhiều nhà sản xuất xe hơi trên thế giới. Nó đang trở thành một tiêu chuẩn "thực tế" cho lập trình C trong toàn bộ ngành công nghiệp hệ thống nhúng, nơi nó được biết đến nhiều nhất. Tuy nhiên, thực tế không có gì trong tài liệu MISRA ngăn nó được sử dụng trong bất kỳ hình thức chương trình C nào. Cả MISRA và CERT đều khá chung chung, cuối cùng họ nhằm mục đích giảm số lượng lỗi, thực tiễn xấu và lỗ hổng trong một chương trình. Các tiêu chuẩn này cũng khuyến khích phân tích mã tĩnh.

1

Sử dụng một tiêu chuẩn hiện có làm cơ sở cho riêng bạn có một số lợi thế. Mã của bạn có thể sẽ giống với mã bên ngoài hơn, giúp đọc / tích hợp mã dễ dàng hơn. Hơn nữa, nếu bạn chọn một tiêu chuẩn tốt, nó sẽ được kiểm tra bởi các chuyên gia có lý do chính đáng để quyết định các quy tắc cụ thể của họ. Miễn là không ai trong nhóm của bạn đặc biệt gắn liền với một tiêu chuẩn, có rất ít lý do để không sử dụng một tiêu chuẩn hiện có làm cơ sở cho chính bạn.

Nếu bạn không chắc chắn nên sử dụng tiêu chuẩn mã hóa nào, có một số lựa chọn lý tưởng đầu tiên rõ ràng. Không theo thứ tự cụ thể:
1. Bất kỳ tiêu chuẩn nào đã được IDE của bạn hỗ trợ. Đây có lẽ là cấu hình.
2. Bất kỳ tiêu chuẩn nào được sử dụng / khuyến nghị bởi tác giả của trình biên dịch của bạn.
3. Bất kỳ tiêu chuẩn nào được sử dụng / khuyến nghị bởi tác giả của khung chính của bạn (nếu có tồn tại).
4. Bất kỳ tiêu chuẩn nào được sử dụng / khuyến nghị bởi tác giả / nhà thiết kế (s) ngôn ngữ lập trình của bạn.
5. Bất kỳ tiêu chuẩn nào được sử dụng / khuyến nghị bởi một công ty rất lớn.

Tôi đề nghị ai đó có chuyên môn kỹ thuật đọc bất kỳ tiêu chuẩn nào bạn đang sử dụng làm cơ sở cho tiêu chuẩn của riêng bạn. Một tiêu chuẩn tốt thường sẽ có sự biện minh cho từng quy tắc, điều này sẽ giúp bạn sửa đổi tiêu chuẩn để phù hợp nhất với nhu cầu của bạn.


0

Một tiêu chuẩn thường giúp giao tiếp và bảo trì. Theo tôi, nó phải tuân theo một số cho và nhận, đặc biệt là trong các đội nhỏ, và nên phát triển. Gọi cho họ hướng dẫn có thể giúp :-)

Hãy xem hướng dẫn của Google để lấy cảm hứng.


5
Rất chủ quan khi chọn hướng dẫn mã hóa cho C / C ++. Và nếu có một cái tôi sẽ không chọn, thì đó là Google. Họ cấm nhiều thứ thường được coi là phong cách C ++ hiện đại tốt bởi những người khác như boost.
Jan Hudec

1
Làm thế nào để câu trả lời của bạn giải quyết mối quan tâm của OP về việc sử dụng một tiêu chuẩn bên ngoài? Đề xuất thay đổi tên cho các tiêu chuẩn mã hóa không giúp ích cho các vấn đề cốt lõi mà họ sẽ cần giải quyết.

1
@JanHudec Tôi đồng ý. Một trong những điều nó cấm là sử dụng ngoại lệ.
BЈовић

-3

KHÔNG, tôi sẽ không bận tâm - Tôi nghĩ lợi ích duy nhất sẽ là nếu nhóm của bạn chuyển đến một nơi mà những tiêu chuẩn đó cũng được sử dụng, đó không phải là điều bạn muốn xảy ra :)

Các tiêu chuẩn chỉ có ở đó để khuyến khích sự hợp tác dễ dàng hơn, vì vậy nếu bạn biết rằng macro #define luôn ở dạng chữ hoa, thì khi bạn nhìn thấy một mã định danh chữ hoa trong mã, bạn sẽ có ý tưởng công bằng về macro. Tương tự, các quy ước đặt tên hoặc quy ước về phong cách khác sẽ nhắc nhở bạn những gì bạn đang giải quyết.

Tôi thấy các tiêu chuẩn như vị trí tệp và tên hữu ích hơn1 là các mã (sau tất cả, mã có đủ hình dạng và kích cỡ và bạn vẫn phải đọc nó) trong khi không biết readme.txt nằm trong / bin / doc / debug / phát hành / tài liệu là một nỗi đau thực sự (như là một con đường nhảm nhí, nhưng đó là một câu chuyện khác).

Tôi sẽ khuyên bạn nên đưa ra tiêu chuẩn của riêng bạn khi bạn đi cùng. Bằng cách đó, bạn không chỉ có được những người bạn thích, mà bạn còn có được những người chắc chắn phù hợp với bạn, nhóm của bạn và công việc bạn làm. Nếu bạn quyết định rằng bạn không thực sự quan tâm vòng lặp while trông như thế nào, hoặc câu lệnh tình huống đó phải được thụt vào theo một cách nhất định, thì bạn tốt. Nếu bạn quyết định rằng các toán tử ++ bị cấm, thì cũng tốt. Tất cả sự lựa chọn của riêng bạn.

Bạn phải làm cho nó dễ dàng tìm thấy và cập nhật nó, một trang web có thể hoặc tự động tạo wiki từ một mô tả văn bản, nhưng nếu không - hãy tìm nó. Các tiêu chuẩn có một thái độ hoang đường từ một số người quan tâm đến việc cuồng tín tuân theo tiêu chuẩn hơn là viết mã tốt, đừng giống như họ - tạo ra tiêu chuẩn của riêng bạn giúp bạn ở nơi bạn cần.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.