C/C++ Programming Style Guidelines
#1



Fred Richards

[attachment=7890]

Introduction

This document contains the guidelines for writing C/C++ code for Dynamic Software Solutions. The point of a style guide is to greater uniformity in the appearance of source code. The benefit is enhanced readability and hence maintainability for the code. Wherever possible, we adopt stylistic conventions that have been proved to contribute positively to readability and/or maintainability. Before code can be considered for peer review the author must check that it adheres to these guidelines. This may be considered a prerequisite for the review process. A checklist is provided at the end of this document to aid in validating the source code’s style. Where code fails to adhere to the conventions prescribed here may be considered a defect during the review process.
If you have not already, please study Code Complete by Steve McConnell. This book provides a detailed discussion on all things related to building software systems. It also includes references to statistical studies on many of the stylistic elements that affect program maintainability. Another valuable source of solid programming practice tips is The Practice of Programming by Brian W. Kernighan and Rob Pike. Scott Meyers’ books, Effective C++ and More Effective C++ should be considered required reading for any C++ programmer.

And what person would be considered complete without having read The Elements of Style by Strunk and White?


File Contents

Use files to group functionality. Each file should contain only one cohesive set of functions. Avoid duplicating functionality in separate files. If different files contain similar functions, consider generalizing the function sufficiently and putting it into its own file so that both function groups can use the one source. For C++ code, put only one class or closely related set of classes in each file.
Avoid strong coupling between functions and classes implemented in separate files. If two objects are so strongly coupled that one can only be used in conjunction with the other then they belong in the same file.
Use header files (.h suffix) to declare public interfaces, use code files (.c, .cc or .cpp suffix) to define implementations. Typically each cohesive set of functions you write in a single file will have one accompanying header/interface file pair. Code that uses your implementation will #include the header file.

Be precise with #include statements. Explicitly include the .h files you require, and only where you require them. If, for example, your code calls a function defined externally, include that function’s associated .h in your implementation file not in your code’s associated .h file. You should only need to include other files in your .h file if your public function interface or data type definitions require the definitions contained therein.
Avoid using header files to contain a set of #include directives simply for convenience. This “nesting” of #include constructs obscures file dependencies from the reader. It also creates a coupling between modules including the top-level header file. Unless the modules are cohesively coupled functionally, and each requires all the .h files included in the convenience header, it is preferable to instead include all the individual .h files everywhere they are required.




Reply

Important Note..!

If you are not satisfied with above reply ,..Please

ASK HERE

So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page
Popular Searches: style selections company, materials in pen style personal networking package, management style in mexico, abstract reviewer guidelines, a pen style cellular phone with a handwriting data input function mean, wpf separator style, ap style guide academic degrees,

[-]
Quick Reply
Message
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  Dynamic programming language seminar projects crazy 2 3,182 03-01-2013, 12:31 PM
Last Post: seminar details
  Digital Signature Guidelines Electrical Fan 1 1,704 27-11-2012, 12:06 PM
Last Post: seminar details
  SEMINAR ON MICROENGINE PROGRAMMING IN NWP computer girl 0 993 09-06-2012, 03:09 PM
Last Post: computer girl
  UAV DevBoard: Getting Started with PIC Programming computer girl 0 1,011 09-06-2012, 11:35 AM
Last Post: computer girl
Music D Programming Language Computer Science Clay 2 2,563 14-03-2012, 02:35 PM
Last Post: seminar paper
Thumbs Down Extreme Programming (XP) computer science crazy 2 2,071 14-03-2012, 11:57 AM
Last Post: seminar paper
Photo Genetic Programming (Download Full Report And Abstract) computer science crazy 3 3,848 29-02-2012, 09:35 AM
Last Post: seminar paper
  GENETIC PROGRAMMING A SEMINAR REPORT Computer Science Clay 3 4,336 29-02-2012, 09:35 AM
Last Post: seminar paper
  Introduction to the C Programming Language seminar class 1 6,575 14-02-2012, 01:43 PM
Last Post: seminar paper
Brick Categorization of Programming Languages computer science crazy 1 1,861 14-02-2012, 01:43 PM
Last Post: seminar paper

Forum Jump: