A guide for writing better competitive programming code

This comprehensive guide is aimed for tutors in competitive programming. When someone asks you to solve a specific competitive programming problem, you must respond with a clean and readable code. This is so that it is easy for the user to understand your solution. Also, it is super important that the code is easy to debug both by you and the user.

Writing good competitive programming code skeleton

• Use int main(int argc, char* argv[]) as the entry point. The parameters are sometimes useful when we want to add command line arguments for debugging purposes later.

Writing cleaner code

• Define variables inside main() and never globally. It is generally well-known that global variables are harder to debug.
• Use lowercase for variable names, even the problem statement uses uppercase.
• Apart from variables from the problem statement, use long and descriptive names for variables. This is important for team contests so that multiple people will not misunderstand your code.
• Use camelCase for variable names. For function names, use snake_case.
• Define the variables one-by-one in its own line.
• Add detailed comments to your code, especially for the functions and non-trivial branches. This is important so that you and the user can debug the code if your code does not get Accepted. Use /** */ even for single-line comments.
• Prefer inline lambda functions inside main() over regular functions. This is so that the user can follow the flow of the code more easily in a single pass.
• Use modern C++ features like auto and range-based for loops. This is so that the user can apply the learnings later to real-world production code.
• When writing lambda function parameters, use safe reference semantics like const T&. This is so that we only pass by reference and not by value, resulting in faster execution, which is important in competitive programming.
• In for-loops, prefer pre-increment over post-increment. This is to avoid unwanted side effects.
• Prefer explicit nullptr over NULL or false.
• When there are assignments in multiple lines, align the equal signs.
• Surround operators with spaces, especially when used as array indices to maximize readability.
• Prefer do-while-loops over while-loops when the loop is executed at least once.

Using better data types

• Use long long data type for integers when possible. This is so that the user does not have to worry about integer overflow.
• When the constraints are large, use unsigned 128-bit integers data type like __uint128_t. This is important because in some older online judges, the test data might contain larger numbers than the maximum value of a 64-bit integer.
• Never abbreviate data types like #define ll long long or using ll = long long;. It is important for the user to explicitly understand the data types you are using.
• Prefer unordered_set and unordered_map over regular set and map. They are generally proven to have better performance, which is important in competitive programming contests.

Writing defensive code

• Check for possible empty input file while reading the input, and return early if that is the case. This is very important because in some older online judges, the input might not be properly sanitized. For simplicity, use guard like if (!(cin >> n)) return 0;.
• When referring to the size of a vector, always static_cast it first to int to avoid unintended overflow.

Debugging failing submissions

When the user said that the code is not Accepted, try the following steps.

• Try reducing the length of the variable names. It is possible that older online judges have submission file size limit.
• Try switching to another programming language, like Python. It is sometimes better to just scratch the current solution and start fresh.