Skip to content

[WIP] Coding Style Guide #3026

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
146 changes: 146 additions & 0 deletions doc/src/dev/coding_style.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,146 @@

Use of `auto`
=============

Use `auto` only when the type is long, complex, or hard to write explicitly.

Examples where `auto` is appropriate:

.. code-block:: cpp

auto it = container.begin(); // Iterator type is long and not helpful to spell out

// The return type is std::vector<std::vector<std::pair<int, float>>>
auto matrix = generate_adjacency_matrix();

// Lambdas have unreadable and compiler-generated types — use auto for them
auto add = [](int x, int y) { return x + y; };


Avoid `auto` when the type is simple and clear:

.. code-block:: cpp

// Use type names when they are short and readable.
for (RRNodeId node_id : device_ctx.rr_graph.nodes()) {
t_rr_node_route_inf& node_inf = route_ctx.rr_node_route_inf[rr_id];
}

int count = 0;
std::string name = "example";
std::vector<int> numbers = {1, 2, 3};

Avoid:

.. code-block:: cpp

auto count = 0; // Simple and obvious type
auto name = std::string("x"); // Hides a short, clear type

for (auto node_id : device_ctx.rr_graph.nodes()) {
// node_id is RRNodeId. Write it out for clarity.
auto& node_inf = route_ctx.rr_node_route_inf[rr_id];
// node_inf is t_rr_node_route_inf. Use the explicit type since it's simple and meaningful.
}

Rationale: clear, explicit types help with readability and understanding. Avoid hiding simple types behind `auto`.



Commenting Style
================

Comments help readers understand the purpose, structure, and reasoning behind the code.
This section outlines when and how to use comments in a consistent and helpful way.

General Rules
-------------

- Focus on explaining *why* the code exists or behaves in a certain way.
- Do not explain *what* the code is doing if it's already clear from the code itself.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.h file should say what the code does; if not obvious explain why the code behaves that way as well.
.cpp file should explain how the code works if it is not obvious.

- Keep comments up to date. Outdated comments are worse than no comments.
- Use Doxygen-style `/** ... */` or `///` for documenting APIs, classes, structs, members, and files.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Follow the instructions at <link> to add new utilities, APIs or internal functionality doxygen documentation to the html pages at <link>.

Comment types and rules:

- Use `/* ... */` **only** for Doxygen documentation comments.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd weaken this a bit / explain the reasoning. Seem a bit strong on the /* vs. //

Do **not** use block comments (`/* */`) to describe code logic or individual lines in function bodies.

- Use `//` for all regular comments within function bodies or implementation code.

Formatting rules for `//` comments:

- Always include a space between `//` and the comment text.
- Use full sentences when appropriate.
- For multi-line comments, prefix each line with `// `.

Incorrect usage:

.. code-block:: cpp

/* Check if visited */ // Block comments are not allowed here
if (visited[node_id]) {
return;
}

//Missing space
//inconsistent formatting

/* Non-Doxygen block comment */ // Not permitted

When to Comment
---------------

**1. File-Level Comments**
- Every source/header file should begin with a brief comment explaining the overall purpose of the file.

**2. Classes and Structs**
- Add a comment describing what the class or struct is for.
- Comment every member variable to explain its role.

Example:
.. code-block:: cpp

/**
* @brief Manages TCP connections for a server.
*/
class ConnectionManager {
public:
/**
* @brief Starts listening for incoming connections.
*/
void Start();

private:
int port_; ///< Listening port.
bool is_running_; ///< Whether the server is active.
};


**3. Functions**
- All non-trivial functions must have a Doxygen comment in the header file or on the static declaration.
- Explain what the function does, its parameters, and its return value.

Example:
.. code-block:: cpp

/**
* @brief Estimates the wirelength of a net using bounding box.
*
* @param net_id ID of the net to analyze.
* @return Estimated wirelength in units.
*/
float estimate_wirelength(ClusterNetId net_id);

Example:
.. code-block:: cpp

// Skip ignored nets
if (net.is_ignored()) {
continue;
}




Copy link
Contributor

@vaughnbetz vaughnbetz May 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other guidelines:

  • Prefer short functions, so they can be reused and their purpose can be more easily commented.
  • Avoid unnecessary use of complex language features; prefer easier-to-read code
  • Check the code and documentation at to see if a utility or routine already exists before making a new one
  • Group related data into structs or classes, and comment each data member and member function

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assertion guidelines:

  • use assertions and data structure validators wherever possible.
  • In CPU-critical code, use VTR_ASSERT_SAFE for potentially expensive checks <link>


1 change: 1 addition & 0 deletions doc/src/dev/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -11,5 +11,6 @@ Developer Guide
c_api_doc
code_documentation
tutorials/index
coding_style
../SUPPORT
../LICENSE