Authors: Nathan Wang, Benjamin Qi, Qi Wang

Contributors: Maggie Liu, Sathvik Chundru

### Prerequisites

StepsCode ConventionsGeneralC++

See Working With MDX for additional information.

## Steps

1. Fork the GitHub repository.

2. If you are adding a solution to a problem within a module, don't create a new file. If you are adding an internal solution, create a new mdx file in solutions/<division>/ if it doesn't already exist, including frontmatter. Use solutions/silver/usaco-690.mdx as an example:

---
id: usaco-690
source: USACO Silver 2017 January
title: Cow Dance Show
---

[Official Analysis](http://www.usaco.org/current/data/sol_cowdance_silver_jan17.html)

## Explanation

Use \texttt{} around variable names with length *greater than one*, like so. Place long equations on separate lines with display math, and use \cdot instead of * to denote multiplication.

$$\texttt{arr}[i]=2\cdot (a+b+c+d+e)+\sum_{j=0}^{i-1}\texttt{arr}[j]$$

Some additional text styles which you might consider using:

http://latexref.xyz/Font-styles.html

http://applied-r.com/latex-font-styles/

$func(var)$

$\textit{func(var)}$

$\textrm{func(var)}$

$\text{func(var)}$

$\textsf{func(var)}$

$\textbf{func(var)}$

$\texttt{func(var)}$

## Implementation

**Time Complexity:** $\mathcal{O}(N\log^2N)$

^ Format time complexity like this. Should appear outside of <LanguageSection> if it's the same for all implementations.

<LanguageSection>

<CPPSection>

</CPPSection>

<PySection>

(if you have Python code)

</PySection>

<JavaSection>

(if you have Java code)

</JavaSection>

</LanguageSection>

Keep file names and solution IDs consistent. In particular, the ID for a USACO problem (such as the one above) is the number at the very end of the URL on usaco.org. The name of a solution file should match the ID of the solution it contains. See Working With MDX for more examples of IDs.

3. Add your implementation, following these conventions below. It is not necessary to add an alternative implementation in the same language as the official implementation unless the alternative implementation takes a different approach or is better than the official one.

4. In the module's .problems.json file (in this case, Binary_Search.problems.json), set solutionMetadata to { "kind": "internal" }. Also add tags (if you want). If the problem is not in a module, you can add the problem to extraProblems.json. If the solution has hints, also specify that in solutionMetadata.

{
"uniqueId": "usaco-690",
"name": "Cow Dance Show",
"url": "http://www.usaco.org/index.php?page=viewproblem2&cpid=690",
"source": "Silver",
"difficulty": "Easy",
"isStarred": false,
"tags": ["Binary Search", "Sorted Set"],
"kind": "internal",
// "hasHints": true
// ^ uncomment the line above if the solution has hints
}
},
5. Check that both the module and the solution render properly using the live editor before submitting a pull request.

## Code Conventions

Your code will be automatically formatted using pre-commit. We strive for code that is readable and understandable. If any code does not compile or is hard to read, contact us.

Read our guidelines below before contributing code.

### General

• Indentation will automatically be converted to tabs.

• In general, do not include unused code (e.g. "templates").

• There are some exceptions to this guideline (e.g. when using the Kattio class for Java I/O). In this case, collapse it with a CodeSnip.
• Use universally understandable variable names, especially for Bronze and Silver. They should be more descriptive than what you would normally use in-contest.

But remember: while comments are very important, the best code is self-documenting. Giving sensible names to types and variables is much better than using obscure names that you must then explain through comments.

In general the actual name of the variable should be descriptive enough to give a good idea of what the variable is used for.

Self-describing code doesn't need a comment.

• Don't repeat yourself.

• Once you've finished making the changes requested by a review, make sure to re-request the review.

C++

### C++

• Do not use variable names that could conflict with using namespace std. For example, don't name a std::set "set."

• Do not use variable-length arrays as discussed here; they are not part of the C++ standard.

• Do not include code that doesn't do anything. In particular,

• Do not include cout.tie(nullptr) as discussed here.
• Do not include optimization pragmas unless you show that they improve performance.
• For Bronze through Gold in particular, do not use additional macros (especially loop macros) beyond the ones listed below (see Github #806):

 Code Snippet: C++ Short Template (Click to expand)int main() { setIO(); }

Resources
LLVM

How to automatically format C++ code with links to style guides

CF

C++ style guide

useful reference, but mostly not relevant to competitive programming

C++ code is automatically formatted using clang-format with the following settings:

TabWidth: 4
IndentWidth: 4
UseTab: ForIndentation
AllowShortIfStatementsOnASingleLine: AllIfsAndElse
AllowShortBlocksOnASingleLine: Always
AllowShortFunctionsOnASingleLine: All
AllowShortLambdasOnASingleLine: All
AllowShortLoopsOnASingleLine: true
SpacesBeforeTrailingComments: 2

Java

### Java

• Regarding I/O, Scanner is significantly slower than BufferedReader and should be avoided. You may use your own I/O template, but collapse it as described above.
• It is good practice to not use constant size arrays in Java.
• Use polymorphism when possible.
• For example, List<Integer> list = new ArrayList<>() instead of ArrayList<Integer> list = new ArrayList<>().

Java code is automatically formatted using clang-format with the following settings:

TabWidth: 4
IndentWidth: 4
UseTab: ForIndentation
AllowShortIfStatementsOnASingleLine: AllIfsAndElse
AllowShortBlocksOnASingleLine: Always
AllowShortFunctionsOnASingleLine: All
AllowShortLambdasOnASingleLine: All
AllowShortLoopsOnASingleLine: true
SpacesBeforeTrailingComments: 2

Python

### Python

• Use snake_case to name variables in your code.
Resources