Embedded C Coding StandardTable of

Embedded C Coding Standard
Table of Contents
Introduction 5
Purpose of the Standard 5
Guiding Principles 6
Enforcement Guidelines 10
Deviation Procedure 10
Acknowledgements 11
Copyright Notice 11
1 General Rules 13
1.1 Which C? 13
1.2 Line Widths 15
1.3 Braces 17
1.4 Parentheses 19
1.5 Common Abbreviations 21
1.6 Casts 23
1.7 Keywords to Avoid 25
1.8 Keywords to Frequent 27
2 Comments 30
2.1 Acceptable Formats 30
2.2 Location and Content 32
3 White Space 37

3.1 Spaces 37
3.2 Alignment 41
3.3 Blank Lines 43
3.4 Indentation 44
3.5 Tabs 47
3.6 Linefeeds 49
4 Modules 50
4.1 Naming Conventions 50
4.2 Header Files 52
4.3 Source Files 55
4.4 File Templates 57
5 Data Types 58
5.1 Naming Conventions 58
5.2 Fixed­Width Integers 61
5.3 Signed Integers 63
5.4 Floating Point 65
5.5 Structures and Unions 67
6 Procedures 68
6.1 Naming Conventions 68
6.2 Functions 71
6.3 Function­Like Macros 73
6.4 Tasks 75
6.5 Interrupt Service Routines 77
7 Variables 79
7.1 Naming Conventions 79


7.2 Initialization 82
8 Expressions and Statements 84
8.1 Variable Declarations 84
8.2 If­Else Statements 85
8.3 Switch Statements 89
8.4 Loops 91
8.5 Unconditional Jumps 93
8.6 Equivalence Tests 95
Bibliography 96
Appendix A: Header File Template 98
Appendix B: Source File Template 99
Appendix C: Standard Abbreviations 100



Introduction

Purpose of the Standard
The primary reason for adopting this coding standard is to reduce the number of bugs present in new embedded software (a.k.a., firmware) and in code later added or modified by maintainers. For this reason, specific rules in this document that describe techniques to eliminate or reduce the number of bugs in a program are tagged with the Zero Bugs...Period™ logo below.






Of course, a coding standard cannot by itself eliminate all of the bugs from a complex embedded system. This coding standard is one part of the Zero Bugs… Period™ firmware design methodology. Zero Bugs… Period emphasizes the critical role of developer training, software and system architecture, lightweight effective process, and the culture of a team or organization in keeping bugs out.


Other important reasons for adopting this coding standard include increasing the readability and portability of software, so that firmware may be maintained and reused at lower cost. A coding standard benefits a team of developers and larger organization by reducing the time required by individuals to understand or review the work of peers.
Guiding Principles
This coding standard was developed in accordance with the following guiding principles, which served to focus the authors’ attention and eliminate conflict over items that are sometimes viewed by programmers as personal stylistic preferences:
1. Individual programmers do not own the software they write. All software development is work for hire for an employer or a client and, thus, the end product should be constructed in a workmanlike manner.
2. It is cheaper and easier to prevent a bug from creeping into code than it is to find and kill it after it has entered. A key strategy in this fight is to write code in which the compiler, linker, or a static analysis tool can detect bugs automatically—i.e., before the code is allowed to execute.


3. For better or worse (well, mostly worse), the ISO “standard1” C programming language allows for a significant amount of variability in the decisions made by compiler implementers. These many so- called “implementation-defined,” “unspecified,” and “undefined” behaviors, along with “locale- specific options”, mean that programs compiled from identical C source code may behave very differently at run-time. Such gray areas in the language standard greatly reduce the portability of C programs that are not carefully crafted.
4. This coding standard prioritizes code reliability and portability above execution efficiency or programmer convenience.
5. There are many sources of bugs in software programs. The original programmer creates some bugs. Other bugs result from misunderstandings by those who later maintain, extend, port, and/or reuse the code.









1 [C90] and [C99]


• The number and severity of bugs introduced by the original programmer can be reduced through disciplined conformance with certain coding practices, such as the placement of constants on the left side of an equivalence (==) test.
• The number and severity of bugs introduced by maintenance programmers can also be influenced by the original programmer. For example, appropriate use of portable fixed- width integer types (e.g., int32_t) ensures that no future port of the code will encounter an unexpected overflow.
• The number and severity of bugs introduced by maintenance programmers can also be reduced through the disciplined use of consistent commenting and stylistic practices, so that everyone in an organization can more easily understand the meaning and proper use of variables, functions, and modules.


6. MISRA’s Guidelines for the Use of the C Language2 are more restrictive than this coding standard—but worthy of study. Deviation from any MISRA-C required or advisory rule should be carefully considered. The authors of the MISRA-C guidelines are knowledgeable of the risks of the use of C in safety-critical systems. Our few known differences of opinion with [MISRA04] are identified in the footnotes to this standard. Followers of Netrino’s coding standard may wish to adopt the other rules of MISRA-C in addition to the rules found here.
7. To be effective, coding standards must be enforceable. Wherever two or more competing rules would be similarly able to prevent bugs but only one of those rules can be enforced automatically, the more enforceable rule is recommended.
In the absence of a needed rule or a conflict between rules, the spirit of the above principles should be applied to guide the decision.










2 [MISRA98] and [MISRA04]


Enforcement Guidelines
Conformance with this coding standard is mandatory.
Non-conforming code shall be made to meet these minimum standards. Non-conforming code shall be detected and removed via automated scans, formal code inspections, or informal discovery. All code that is submitted for a release of the software shall conform to these standards, unless a deviation has been permitted.
Deviation Procedure
At the project level, it is acceptable for another coding standard (such as the coding standard of a client or partner) to be adopted instead of this one. In that case, all members of the project team should follow the selected coding standard.
At the module level, it is only acceptable to deviate from this coding standard with the approval of the project manager. The reason for the deviation and the approver’s name shall be stated as close as possible to the scope of the deviation. For example, a single deviation in a function should be documented in a block comment within or above that function, whichever is most helpful to the next reader.


Acknowledgements
Though my name is the only one on the front of this book, the development of Netrino’s Embedded C Coding Standard was a collaborative effort, involving many at Netrino plus other members of the embedded software community. I am specifically grateful to Nigel Jones, Jack Ganssle, Jean Labrosse, and Miro Samek for publishing earlier firmware coding standards; to Netrino’s Joe Perret and Salomon Singer for getting this project underway in a big way; to Andrew Girson for the numerous discussions leading to Zero Bugs…Period; to Elizabeth Gallauresi for handling various details; and to all of the many technical reviewers who provided important feedback, including Mike Ficco, JR Simma, Dan Smith, Michael Wilk, and several of the other folks already identified.
Copyright Notice
This document and the information it contains is Copyright © 2009 Netrino, LLC (www.netrino.com). It is allowable for individuals, companies, and institutions to adopt all or some of the coding rules herein; indeed we hope many will. This may be done simply by identifying the Netrino Embedded C Coding Standard, and retaining this paragraph in its entirety. All other rights are reserved by Netrino, LLC.




1 General Rules

1.1 Which C?

Rules:

a. All programs shall be written to comply with the latest available ISO Standard for the C Programming Language, which is currently [C99].3
b. Whenever a C++ compiler is used, appropriate compiler options shall be set to restrict the language to the latest standard C subset supported by the compiler.
c. The use of proprietary compiler language keyword extensions, #pragmas, and inline assembly shall be kept to the minimum necessary to get the job done and be localized to a small number of device driver modules that interface directly to hardware.4




3 This deviates from [MISRA04] Rule 1.1. Compilers compatible with [C99] offer many valuable improvements, including support for the fixed-width integer types, C++ style comments, the ability to declare automatic variables where needed, and inline functions. In the absence of a [C99]-compliant compiler, a [C90]-compliant compiler shall be used.
4 This appears to deviate from [MISRA04] Rule 1.1, but is consistent with Rules 2.1 and 3.4, as well as MISRA-forseen deviations from Rule 1.1.


Reasoning: Even “standard” C varies by compiler, but we need as common of a platform as we can find to make possible the rules and enforcement mechanisms that follow. C++ is a different language and the use of C++ and C should not be mixed in the same design; C++ programmers should consult Netrino’s Embedded C++ Coding Standard, which differs substantially from this document.
Exceptions: These rules may be ignored in the case that the compiler supports only an older version of the C standard.
Enforcement: These rules shall be enforced during code reviews.


1.2 Line Widths

Rules:

a. The length of all lines in a program shall be limited to a maximum of 80 characters.
Reasoning: Cod

Kết quả (Việt) 1:

Tiêu chuẩn mã hóa nhúng CBảng nội dungGiới thiệu 5Mục đích của 5 tiêu chuẩnHướng dẫn nguyên tắc 6Hướng dẫn thi hành 10Độ lệch thủ tục 10Lời cảm ơn 11Bản quyền thông báo 11Quy tắc chung 1 131.1 C? 131.2 độ rộng line 151.3 niềng răng 171.4 ngoặc 191.5 phổ biến chữ viết tắt 211.6 phôi 231.7 các từ khóa để tránh 251.8 các từ khóa để thường xuyên 272 ý kiến 302.1 chấp nhận được định dạng 302.2 địa điểm và nội dung 323 không gian màu trắng 37 3.1 tại 373.2 liên kết 413.3 dòng trống 433.4 indentation 443.5 tabs 473,6 Linefeeds 494 mô-đun 504.1 quy ước đặt tên 504.2 tập tin tiêu đề 524.3 nguồn tập tin 554,4 tập tin mẫu 57Loại dữ liệu 5 585.1 quy ước đặt tên 585.2 số nguyên FixedWidth 615.3 ký số nguyên 635.4 nổi điểm 655.5 các cấu trúc và công đoàn 67Thủ tục 6 686.1 quy ước đặt tên 686.2 chức năng 716.3 functionLike macro 736.4 nhiệm vụ 756,5 làm gián đoạn dịch vụ thói quen 777 biến 797.1 quy ước đặt tên 79 7.2 khởi tạo 828 biểu hiện và báo cáo 848.1 khai báo biến 848.2 báo cáo IfElse 858.3 switch báo cáo 898.4 vòng 918.5 vô điều kiện nhảy 938.6 bài kiểm tra tương đương 95Tài liệu tham khảo 96Phụ lục một: tiêu đề tập tin mẫu 98Phụ lục B: nguồn tập tin mẫu 99Phụ lục C: tiêu chuẩn chữ viết tắt 100 Giới thiệuMục đích của các tiêu chuẩnLý do chính cho việc áp dụng tiêu chuẩn mã hóa này là để giảm số lỗi xuất hiện trong phần mềm nhúng mới (aka, phần mềm) và trong mã sau đó thêm hoặc sửa đổi bởi maintainers. Vì lý do này, quy định cụ thể trong tài liệu này mô tả các kỹ thuật để loại bỏ hoặc giảm số lỗi trong một chương trình được gắn thẻ với các lỗi Zero... Giai đoạn ™ biểu tượng dưới đây. Tất nhiên, một tiêu chuẩn mã hóa không thể tự loại bỏ tất cả các lỗi từ hệ thống nhúng phức tạp. Tiêu chuẩn mã hóa này là một phần của Zero lỗi... Giai đoạn ™ các phương pháp thiết kế phần mềm. Lỗi không... Thời kỳ nhấn mạnh vai trò quan trọng của các nhà phát triển đào tạo, kiến trúc phần mềm và hệ thống, trọng lượng nhẹ trình hiệu quả và các nền văn hóa của một nhóm hay tổ chức trong việc giữ lỗi. Các lý do quan trọng cho việc áp dụng tiêu chuẩn mã hóa này bao gồm tăng dễ đọc và tính di động của phần mềm, do đó phần vững có thể được duy trì và tái sử dụng chi phí thấp hơn. Một tiêu chuẩn mã hóa lợi ích một nhóm các nhà phát triển và tổ chức lớn hơn bằng cách giảm thời gian cần thiết bởi các cá nhân để hiểu hoặc xem xét công việc của đồng nghiệp.Nguyên tắc hướng dẫnTiêu chuẩn mã hóa này được phát triển phù hợp với các nguyên tắc hướng dẫn sau đây, phục vụ để tập trung sự chú ý của các tác giả và loại bỏ xung đột trên mặt hàng mà đôi khi được xem bởi lập trình viên như sở thích cá nhân phong cách:1. cá nhân lập trình không sở hữu phần mềm họ viết. Tất cả các phát triển phần mềm là làm việc cho thuê cho một chủ nhân hoặc một khách hàng, và như vậy, sản phẩm cuối cùng cần được xây dựng theo trường.2. It is cheaper and easier to prevent a bug from creeping into code than it is to find and kill it after it has entered. A key strategy in this fight is to write code in which the compiler, linker, or a static analysis tool can detect bugs automatically—i.e., before the code is allowed to execute. 3. For better or worse (well, mostly worse), the ISO “standard1” C programming language allows for a significant amount of variability in the decisions made by compiler implementers. These many so- called “implementation-defined,” “unspecified,” and “undefined” behaviors, along with “locale- specific options”, mean that programs compiled from identical C source code may behave very differently at run-time. Such gray areas in the language standard greatly reduce the portability of C programs that are not carefully crafted.4. This coding standard prioritizes code reliability and portability above execution efficiency or programmer convenience.5. There are many sources of bugs in software programs. The original programmer creates some bugs. Other bugs result from misunderstandings by those who later maintain, extend, port, and/or reuse the code. 1 [C90] and [C99] • The number and severity of bugs introduced by the original programmer can be reduced through disciplined conformance with certain coding practices, such as the placement of constants on the left side of an equivalence (==) test.• The number and severity of bugs introduced by maintenance programmers can also be influenced by the original programmer. For example, appropriate use of portable fixed- width integer types (e.g., int32_t) ensures that no future port of the code will encounter an unexpected overflow.
• The number and severity of bugs introduced by maintenance programmers can also be reduced through the disciplined use of consistent commenting and stylistic practices, so that everyone in an organization can more easily understand the meaning and proper use of variables, functions, and modules.


6. MISRA’s Guidelines for the Use of the C Language2 are more restrictive than this coding standard—but worthy of study. Deviation from any MISRA-C required or advisory rule should be carefully considered. The authors of the MISRA-C guidelines are knowledgeable of the risks of the use of C in safety-critical systems. Our few known differences of opinion with [MISRA04] are identified in the footnotes to this standard. Followers of Netrino’s coding standard may wish to adopt the other rules of MISRA-C in addition to the rules found here.
7. To be effective, coding standards must be enforceable. Wherever two or more competing rules would be similarly able to prevent bugs but only one of those rules can be enforced automatically, the more enforceable rule is recommended.
In the absence of a needed rule or a conflict between rules, the spirit of the above principles should be applied to guide the decision.










2 [MISRA98] and [MISRA04]


Enforcement Guidelines
Conformance with this coding standard is mandatory.
Non-conforming code shall be made to meet these minimum standards. Non-conforming code shall be detected and removed via automated scans, formal code inspections, or informal discovery. All code that is submitted for a release of the software shall conform to these standards, unless a deviation has been permitted.
Deviation Procedure
At the project level, it is acceptable for another coding standard (such as the coding standard of a client or partner) to be adopted instead of this one. In that case, all members of the project team should follow the selected coding standard.
At the module level, it is only acceptable to deviate from this coding standard with the approval of the project manager. The reason for the deviation and the approver’s name shall be stated as close as possible to the scope of the deviation. For example, a single deviation in a function should be documented in a block comment within or above that function, whichever is most helpful to the next reader.


Acknowledgements
Though my name is the only one on the front of this book, the development of Netrino’s Embedded C Coding Standard was a collaborative effort, involving many at Netrino plus other members of the embedded software community. I am specifically grateful to Nigel Jones, Jack Ganssle, Jean Labrosse, and Miro Samek for publishing earlier firmware coding standards; to Netrino’s Joe Perret and Salomon Singer for getting this project underway in a big way; to Andrew Girson for the numerous discussions leading to Zero Bugs…Period; to Elizabeth Gallauresi for handling various details; and to all of the many technical reviewers who provided important feedback, including Mike Ficco, JR Simma, Dan Smith, Michael Wilk, and several of the other folks already identified.
Copyright Notice
This document and the information it contains is Copyright © 2009 Netrino, LLC (www.netrino.com). It is allowable for individuals, companies, and institutions to adopt all or some of the coding rules herein; indeed we hope many will. This may be done simply by identifying the Netrino Embedded C Coding Standard, and retaining this paragraph in its entirety. All other rights are reserved by Netrino, LLC.




1 General Rules

1.1 Which C?

Rules:

a. All programs shall be written to comply with the latest available ISO Standard for the C Programming Language, which is currently [C99].3
b. Whenever a C++ compiler is used, appropriate compiler options shall be set to restrict the language to the latest standard C subset supported by the compiler.
c. The use of proprietary compiler language keyword extensions, #pragmas, and inline assembly shall be kept to the minimum necessary to get the job done and be localized to a small number of device driver modules that interface directly to hardware.4




3 This deviates from [MISRA04] Rule 1.1. Compilers compatible with [C99] offer many valuable improvements, including support for the fixed-width integer types, C++ style comments, the ability to declare automatic variables where needed, and inline functions. In the absence of a [C99]-compliant compiler, a [C90]-compliant compiler shall be used.
4 This appears to deviate from [MISRA04] Rule 1.1, but is consistent with Rules 2.1 and 3.4, as well as MISRA-forseen deviations from Rule 1.1.


Reasoning: Even “standard” C varies by compiler, but we need as common of a platform as we can find to make possible the rules and enforcement mechanisms that follow. C++ is a different language and the use of C++ and C should not be mixed in the same design; C++ programmers should consult Netrino’s Embedded C++ Coding Standard, which differs substantially from this document.
Exceptions: These rules may be ignored in the case that the compiler supports only an older version of the C standard.
Enforcement: These rules shall be enforced during code reviews.


1.2 Line Widths

Rules:

a. The length of all lines in a program shall be limited to a maximum of 80 characters.
Reasoning: Cod

Kết quả (Việt) 2:

C nhúng Mã hóa Chuẩn
Table of Contents
Giới thiệu 5
Mục đích của tiêu chuẩn 5
nguyên tắc hướng dẫn 6
Thi hành Hướng dẫn 10
Độ lệch Thủ tục 10
Lời cảm ơn 11
Copyright Notice 11
Rules 1 chung 13
1.1 Những C? 13
1.2 Dòng Widths 15
1.3 Niềng răng 17
1.4 Dấu ngoặc 19
viết tắt 1.5 Common 21
1.6 Casts 23
1.7 Từ khoá để Tránh 25
1.8 Từ khoá để thường xuyên 27
2 Comments 30
2.1 Các định dạng được chấp nhận 30
2.2 Địa điểm và nội dung 32
3 trắng Space 37 3.1 Không gian 37 3.2 Alignment 41 3.3 Dây chuyền Trống 43 3.4 lõm 44 3.5 Tabs 47 3.6 Linefeeds 49 4 Mô-đun 50 4.1 Quy ước đặt tên 50 4.2 Tiêu đề tập tin 52 4.3 Nguồn tập tin 55 4.4 File Templates 57 5 kiểu dữ liệu 58 5.1 Quy ước đặt tên 58 5.2 FixedWidth số nguyên 61 5.3 Số nguyên Signed 63 5.4 Floating điểm 65 5.5 Cấu trúc và đoàn 67 6 Thủ tục 68 6.1 Quy ước đặt tên 68 6.2 Chức năng 71 6.3 FunctionLike Macros 73 6.4 Nhiệm vụ 75 6.5 Interrupt Service Routines 77 7 biến 79 7.1 Quy ước đặt tên 79 7.2 Khởi tạo 82 8 Expressions và báo cáo 84 8.1 Khai báo biến 84 8.2 IfElse báo cáo 85 8.3 Chuyển báo cáo 89 8.4 Loops 91 8.5 Unconditional Jumps 93 8.6 Tính tương đương Tests 95 Tài liệu tham khảo 96 Phụ lục A: Tiêu đề file Template 98 Phụ lục B: Source File Mẫu 99 Phụ lục C: Chuẩn viết tắt 100 Giới thiệu Mục đích của tiêu chuẩn Lý do chính cho việc áp dụng này mã hóa tiêu chuẩn là để giảm số lượng các lỗi có trong phần mềm mới nhúng (aka, firmware) và trong mã sau thêm hoặc thay đổi bởi người duy trì. Vì lý do này, các quy định cụ thể trong tài liệu này mô tả các kỹ thuật để loại bỏ hoặc giảm số lượng các lỗi trong một chương trình được gắn thẻ với Zero Bugs ... Thời gian biểu tượng ™ dưới đây. Tất nhiên, một tiêu chuẩn mã hóa có thể không tự loại bỏ tất cả các lỗi từ một hệ thống nhúng phức tạp. Tiêu chuẩn mã hóa này là một phần của Zero Bugs ... Thời kỳ phương pháp thiết kế firmware ™. Zero, Bugs ... Thời gian nhấn mạnh vai trò quan trọng của đào tạo phát triển, phần mềm và kiến trúc hệ thống, quá trình hiệu quả trọng lượng nhẹ, và văn hóa của một nhóm hay tổ chức trong việc giữ lỗi ra. Lý do quan trọng khác cho việc áp dụng tiêu chuẩn mã hóa này bao gồm tăng khả năng đọc và tính di động của phần mềm , do firmware có thể được duy trì và tái sử dụng với chi phí thấp hơn. Một tiêu chuẩn mã hóa lợi ích cho một nhóm các nhà phát triển và các tổ chức lớn hơn bằng cách giảm thời gian yêu cầu của cá nhân để hiểu hoặc xem xét lại công việc của đồng nghiệp. Hướng dẫn nguyên tắc tiêu chuẩn mã hóa này đã được phát triển phù hợp với các nguyên tắc sau đây hướng dẫn, mà phục vụ để tập trung sự chú ý của các tác giả và loại bỏ các xung đột về mặt hàng mà đôi khi được xem bởi các lập trình viên như sở thích phong cách cá nhân: 1. Lập trình viên cá nhân không sở hữu các phần mềm mà họ viết. Tất cả phát triển phần mềm là công việc cho thuê cho một chủ nhân hay một khách hàng và, do đó, các sản phẩm cuối cùng phải được xây dựng một cách như người thợ. 2. Nó là rẻ hơn và dễ dàng hơn để ngăn chặn một lỗi từ len lỏi vào mã hơn là để tìm và tiêu diệt nó sau khi nó đã nhập vào. Một chiến lược quan trọng trong cuộc chiến này là để viết mã trong đó trình biên dịch, trình liên kết, hoặc một công cụ phân tích tĩnh có thể phát hiện lỗi tự động-tức là, trước khi mã được phép thực hiện. 3. Cho tốt hơn hoặc tồi tệ hơn (tốt, chủ yếu là tồi tệ hơn), các tiêu chuẩn ISO "standard1" ngôn ngữ lập trình C cho phép một số lượng đáng kể các biến đổi trong các quyết định của người thực hiện biên dịch. Những nhiều cái gọi là "thực hiện xác định", "không xác định", và "" hành vi, cùng với "không xác định cụ thể lựa chọn locale-", có nghĩa là chương trình biên dịch từ mã nguồn C giống hệt nhau có thể cư xử rất khác nhau tại thời gian chạy. Khu vực màu xám như trong các ngôn ngữ tiêu chuẩn làm giảm đáng kể tính di động của các chương trình C mà không cẩn thận. 4. Tiêu chuẩn mã hóa ưu tiên các mã và độ tin cậy tính di động trên hiệu quả thực hiện hoặc lập trình thuận tiện. 5. Có rất nhiều nguồn lỗi trong các chương trình phần mềm. Các lập trình ban đầu tạo ra một số lỗi. Lỗi khác dẫn đến từ sự hiểu lầm của những người sau này duy trì, mở rộng, cổng, và / hoặc sử dụng lại mã. 1 [C90] và [C99] • Số lượng và mức độ nghiêm trọng của lỗi được giới thiệu bởi các lập trình ban đầu có thể được giảm xuống thông qua sự phù hợp xử lý kỷ luật nhất định thực hành mã hóa, chẳng hạn như vị trí của các hằng số ở phía bên trái của một tương đương (==) thử nghiệm. • Số lượng và mức độ nghiêm trọng của lỗi được giới thiệu bởi các lập trình bảo trì cũng có thể bị ảnh hưởng bởi các lập trình ban đầu. Ví dụ, việc sử dụng các loại nguyên chiều rộng cố định di động (ví dụ, int32_t) đảm bảo rằng không có cổng tương lai của mã này sẽ gặp phải một tràn bất ngờ. • Số lượng và mức độ nghiêm trọng của lỗi được giới thiệu bởi các lập trình bảo trì cũng có thể được giảm thông qua việc sử dụng kỷ luật thực hành phù hợp cho ý kiến và phong cách, để mọi người trong một tổ chức có thể dễ dàng hiểu được ý nghĩa và sử dụng hợp lý các biến, chức năng, và các mô-đun. 6. Hướng dẫn Misra cho việc sử dụng các C Language2 có nhiều hạn chế hơn so với mã hóa tiêu chuẩn nhưng điều này xứng đáng nghiên cứu. Độ lệch từ bất kỳ quy tắc yêu cầu hoặc tư vấn Misra-C cần được xem xét một cách cẩn thận. Các tác giả của các hướng dẫn Misra-C có kiến thức về những nguy cơ của việc sử dụng của C trong các hệ thống an toàn quan trọng. Vài sự khác biệt của chúng tôi biết ý kiến với [MISRA04] được xác định trong các chú thích với chuẩn này. Những người theo tiêu chuẩn mã hóa Netrino của thể muốn áp dụng các quy định khác của Misra-C, thêm vào các quy tắc tìm thấy ở đây. 7. Để có hiệu quả, tiêu chuẩn mã hóa phải được thực thi. Bất cứ nơi nào hai hay nhiều quy tắc cạnh tranh sẽ là tương tự như vậy có thể ngăn ngừa lỗi nhưng chỉ một trong những quy tắc có thể được thực thi tự động, các quy tắc thực thi hơn là khuyến khích. Trong trường hợp không có một quy tắc cần thiết hoặc một cuộc xung đột giữa các quy tắc, tinh thần của các nguyên tắc trên nên được áp dụng để hướng dẫn các quyết định. 2 [MISRA98] và [MISRA04] Thực thi Hướng dẫn sự phù hợp với các tiêu chuẩn mã hóa này là bắt buộc. Không phù hợp đang được thực hiện để đáp ứng các tiêu chuẩn tối thiểu. Không phù hợp đang được phát hiện và loại bỏ thông qua quét tự động, giám định mã chính thức, hoặc khám phá thức. Tất cả các mã được gửi cho một bản phát hành của phần mềm sẽ phù hợp với các tiêu chuẩn, trừ khi một sự sai lệch đã được cho phép. Deviation Procedure Ở cấp dự án, đó là chấp nhận được đối với một tiêu chuẩn mã hóa (ví dụ như các tiêu chuẩn mã hóa của một khách hàng hoặc đối tác) được thông qua thay vì một này. Trong trường hợp đó, tất cả các thành viên của nhóm dự án phải thực hiện theo các tiêu chuẩn mã hóa được lựa chọn. Ở cấp module, nó chỉ là chấp nhận được để đi chệch khỏi tiêu chuẩn mã hóa này với sự chấp thuận của người quản lý dự án. Lý do cho sự sai lệch và tên của người phê duyệt phải được nêu càng gần càng tốt để các phạm vi của độ lệch. Ví dụ, một độ lệch duy nhất trong một chức năng nên được ghi chép trong một bình luận khối trong hoặc trên chức năng, nào là hữu ích nhất cho người đọc tiếp theo. Lời cảm ơn Mặc dù tên của tôi là người duy nhất trên mặt trước của cuốn sách này, sự phát triển của Netrino của C nhúng Mã hóa Chuẩn là một nỗ lực hợp tác, liên quan đến nhiều tại Netrino cộng với các thành viên khác của cộng đồng phần mềm nhúng. Tôi đặc biệt biết ơn Nigel Jones, Jack Ganssle, Jean Labrosse, và Miro Samek cho xuất bản firmware mã hóa tiêu chuẩn trước đó; để Netrino của Joe Perret và Salomon Singer để nhận dự án này được tiến hành một cách lớn; Andrew Girson cho rất nhiều những cuộc tranh luận với Zero Bugs ... Thời gian; Elizabeth Gallauresi để xử lý chi tiết khác nhau; và tất cả các nhận xét ​​kỹ thuật nhiều người đã cung cấp thông tin phản hồi quan trọng, bao gồm Mike Ficco, JR Simma, Dan Smith, Michael Wilk, và một số các folks khác đã được xác định. Notice Copyright tài liệu này và các thông tin mà nó chứa là Copyright © 2009 Netrino, LLC (www.netrino.com). Đó là cho phép đối với các cá nhân, công ty, và các tổ chức để áp dụng tất cả hoặc một số các quy tắc mã hóa tài liệu này; thực sự chúng ta hy vọng nhiều người sẽ. Điều này có thể được thực hiện đơn giản bằng cách xác định các Netrino Embedded C Mã hóa chuẩn, và giữ lại đoạn này trong toàn bộ của nó. Tất cả các quyền khác được bảo vệ bởi Netrino, LLC. 1 Quy định chung 1.1 Trong đó C? Rules: a. Tất cả các chương trình được viết để thực hiện theo các tiêu chuẩn ISO mới nhất có sẵn cho ngôn ngữ lập trình C, hiện đang là [C99] .3 b. Bất cứ khi nào một trình biên dịch C ++ được sử dụng, tùy chọn biên dịch thích hợp được thiết lập để hạn chế ngôn ngữ mới nhất của tiêu chuẩn C tập con được hỗ trợ bởi trình biên dịch. C. Việc sử dụng các phần mở rộng ngôn ngữ biên dịch độc quyền từ khóa, #pragmas, và lắp ráp nội tuyến phải được giữ ở mức tối thiểu cần thiết để có được công việc làm và được địa phương hoá một số lượng nhỏ của các mô-đun trình điều khiển thiết bị có giao diện trực tiếp đến hardware.4 3 này lệch khỏi [ MISRA04] Quy tắc 1.1. Trình biên dịch tương thích với [C99] cung cấp nhiều cải tiến đáng giá, bao gồm hỗ trợ cho các loại nguyên chiều rộng cố định, C ++ comments phong cách, khả năng để khai báo các biến tự động khi cần thiết, và các chức năng nội tuyến. Trong sự vắng mặt của một [C99] -compliant trình biên dịch, một [C90] biên dịch -compliant sẽ được sử dụng. 4 Điều này dường như đi chệch khỏi [MISRA04] Quy tắc 1.1, nhưng phù hợp với quy định 2.1 và 3.4, cũng như Misra-lường độ lệch từ Rule 1.1. Lý luận: Ngay cả C "tiêu chuẩn" thay đổi bởi trình biên dịch, nhưng chúng ta cần phổ biến của một nền tảng như chúng ta có thể tìm thấy để làm tốt các quy tắc và cơ chế thực thi tiếp theo. C ++ là một ngôn ngữ khác nhau và việc sử dụng C ++ và C không nên được trộn lẫn trong cùng một thiết kế; C ++ lập trình nên tham khảo ý kiến Embedded C Netrino của ++ Mã hóa chuẩn, mà về bản chất khác từ tài liệu này. Ngoại lệ: Những quy định này có thể được bỏ qua trong các trường hợp đó, trình biên dịch chỉ hỗ trợ một phiên bản cũ của chuẩn C. Enforcement: Những quy định này sẽ được thi hành trong đánh mã . 1.2 Dòng Widths Rules: a. Chiều dài của tất cả các dòng trong một chương trình được giới hạn tối đa là 80 ký tự. Reasoning: Cod