CodingStyle

From Open64 Wiki

Contents 1 Use of this page 2 General Style 2.1 file consistent 2.2 maximize code reuse 2.3 minimize compilation time 2.4 enable compiler to optimize 2.5 C++ coding style 2.5.1 no inheritance/virtual 2.5.2 avoid static 2.6 avoid ifdef 2.7 no compatibility breaking 2.8 more assertions 2.9 own type 2.10 samples there 3 Debuggability 3.1 Option 3.1.1 option to control 3.2 Tracing 3.2.1 no customized tracing 3.3 Assertion 3.3.1 own assertion 3.4 Macro vs. Inline functions 3.4.1 inline instead of macro 4 Testability 4.1 test case for bug fix 4.2 self contained features 4.3 no assumption across 4.4 semantics consistent 5 Retargetability 5.1 ifdef discouraged 6 sample header file 7 sample cxx file

Use of this page

The document is meant as a guideline for Open64 developers. The purpose is to encourage good software practice. While we want to keep existing practices in open64 that have been proven useful, it is also important to allow modern software practices. We expect people to use this document as a guideline. We also assume that open64 developers are well versed in basics of C or C++ coding conventions and pitfalls. This is not meant to be an exhaustive list of coding style, use this to complement your good programming practice.

General Style

file consistent

• Stay consistent with existing style and convention of the source file
• For each source file, the style should be consistent (e.g. indentation, naming convention, braces, spacing, …)

maximize code reuse

• Maximize code sharing and reuse when possible

minimize compilation time

• Minimize compilation time

enable compiler to optimize

• Word of caution: Instead of writing obscure, heavily hand tuned code that is hard to read, as compiler writers, the code should be such that we allow the compiler maximum opportunity to optimize.

C++ coding style

• Use C++ coding style whenever possible, unless constrained by existing infrastructure.

no inheritance/virtual

• Open64 has traditionally discouraged inheritance and virtual functions, this is still the case today

avoid static

• Use of static is discouraged. In fact, inside WOPT, other than a few variables (such as error code), static is NOT ALLOWED from the very beginning when WOPT was developed

avoid ifdef

• Use of ifdef or "if defined" is discouraged. Try use different practices to accomplish what is needed.

no compatibility breaking

• While we do not guarantee compatibility between compiler builds, whenever possible, avoid breaking compatibility. E.g. if a new operator is introduced, add at the end.

more assertions

• Use of assertions is strongly recommended

own type

• Use type name defined in Open64 ecosystem instead of C++ standard type. E.g. we encourage use of INT32 over int.

samples there

• For the basic styles such as naming, indentation, declaration, include, … we have included a source file and it's include file in Appendix.
• Additional general coding style can be found in appendix A and B. They are written as cxx and .h file. We think real examples are the best to illustrate the recommended convention.

Debuggability

The goal is to enable automatic tools to quickly find out the file, function, basic block, expression, instruction that exhibits a specific problem at hand. Quality, price and users testimonials are those 3 factors that I took into consideration while choosing appropriate writing service to write my essay. I hold my eye on supremeessays.com and have never regretted my choice. They provided me with custom papers of the highest quality. Coding practice should be so that this is possible. This could include choosing the algorithm that enables this over one that cannot (e.g. SSAPRE vs. bit-vector PRE). There should not be assumptions across phases. This is a pre-condition for more accurate automatic triage tool.

Option

option to control

• Each optimization, phase must have option that can be turned off. When applicable, allow Open64's built-in mechanism for binary search to identify the offending instance.

Tracing

no customized tracing

• Open64 has well defined 'tracing' mechanism with controls on file, function, BB level granularity; plus many other whistles and improvements through time (i.e., Get_Trace). Use of new tracing mechanism is not allowed. This tracing mechanism should not be used as options to turn on/off optimization.

Assertion

own assertion

• Open64 has well defined FmtAssert/Is_True/Fatal/DefWarn/… mechanism that is also tied with debug vs. production (or release) build of the compiler. Other forms of "assertion", including the "assert" that comes with C/C++ language spec is not allowed.

Macro vs. Inline functions

inline instead of macro

• Whenever possible, use inline functions instead of macros.
• Use inline/member functions instead of direct field access.

Testability

test case for bug fix

• Each bug fix should have small test case checked into open64 regression suite

self contained features

• Keep new features self contained whenever possible

no assumption across

• No assumption across different phases

semantics consistent

• For each optimization, the IR must remain semantically the same before and after the transformation. E.g. the IR should not need optional expressions to maintain the same semantics.

Retargetability

Although retargetability is not the original design goal, the compiler has been retargeted to more than four different targets. This requirement is becoming more important. We intend to improve this area moving forward.

ifdef discouraged

• Use of ifdef or “if defined” is discouraged. Today, the code is littered with them, obstructing readability, hence maintainability of the code. A better way is to define a flag for target-specific property and then set the flag in target-specific sub-files.

sample header file

• Appendix A (coding_convention.h)

File:Coding convention.h.pdf

sample cxx file

• Appendix B (coding_convention.cxx)

File:Coding convention.cxx.pdf