make modules compile
This commit is contained in:
Benjamin Qi
parent
076f938606
commit
e870c69be9
|
|
@ -58,11 +58,6 @@ For all subsequent modules, `#include <bits/stdc++.h>` will be used in place of
|
|||
|
||||
</CPPSection>
|
||||
|
||||
<JavaSection>
|
||||
|
||||
|
||||
|
||||
</JavaSection>
|
||||
|
||||
</LanguageSection>
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ Difficulty ranges from "Very Easy" to "Insane." Difficulty is **not** comparable
|
|||
|
||||
- "**Intro**" refers to a problem that just asks you to implement a standard algorithm or data structure.
|
||||
- "**Easy**" refers to a problem that can be solved relatively quickly be someone who is familiar with the module, while also approachable by someone who has just finished reading the starred resources.
|
||||
- "**Medium**" refers to a problem which requires a bit more thinking, but can also be solved by people who have done sufficent practice of easy problems.
|
||||
- "**Normal**" refers to a problem which requires a bit more thinking, but can also be solved by people who have done sufficent practice of easy problems.
|
||||
- "**Hard**" refers to a problem which may take a lot of time to approach. However, if someone has done a large number of "Medium" problems and has a strong understanding of a topic, could theoretically be solved during a USACO contest.
|
||||
- "**Very Hard**" refers to a problem that will challenge even very strong contestants and often requires multiple levels of observations and more knowledge than provided by the module.
|
||||
- "**Insane**" refers to problems that are misplaced in their division. These problems are often a bad representation of the difficulty of problems in a USACO division. However, this does not mean that these problems cannot be interesting. If you want a challenge, try them out.
|
||||
|
|
@ -64,69 +64,43 @@ Some modules may also have additional content at the end that isn't needed for U
|
|||
The code we provide will generally follow the conventions below. Please note that you do _not_ have to copy our conventions; there is no "right" convention for coding!
|
||||
|
||||
### C++
|
||||
|
||||
<resources>
|
||||
<resource source = "CF" title = "Competitive C++ Manifesto"> cpp conventions influenced by this blog post</resource>
|
||||
<resource source = "CF" title = "Competitive C++ Manifesto" url="blog/entry/64218"> some material directly from this blog post</resource>
|
||||
</resources>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
Avoid the use of Macros. If you end up using a macro, include the `#define` statement. </li>
|
||||
<li>
|
||||
Indent using 4 spaces. <!-- Avoid using tabs? Does this cause any problems on usaco-guide? --></li>
|
||||
<li>
|
||||
Braces that open on one line should close on another. Always include braces, even if the code inside them is only one line.
|
||||
</li>
|
||||
<li>
|
||||
Braces open on the same line like `if(a == b) {` and have a space directly to the left of the brace. Statements before the brace should be spaced as well, such as `for (int i = 0; i < n; ++i) {`.
|
||||
</li>
|
||||
<li>
|
||||
Semicolons and commas should only be spaced from the right side.
|
||||
</li>
|
||||
<li>
|
||||
Separate multiple operations on the same line with a comma like `a = b, c = d;` or split them into different lines and use semicolons.
|
||||
</li>
|
||||
<li>
|
||||
Use `++x` to increment a variable (ie. in a `for` loop).
|
||||
</li>
|
||||
<li>
|
||||
Start your `else` statment on <!-- different / same? --> the (same?) line of your `if` statement, like so:
|
||||
<!-- Avoid using tabs? Does this cause any problems on usaco-guide? -->
|
||||
|
||||
<!-- Any preferences? Also, this doesn't apply to the custom sorting module, make sure to include all 3! :) -->
|
||||
|
||||
- Use `using namespace std` rather than `std::`.
|
||||
- Indent using tabs.
|
||||
- Avoid the use of macros. If you end up using a macro, include the `#define` statement.
|
||||
- Braces that open on one line should close on another. Always include braces, even if the code inside them is only one line.
|
||||
- Braces open on the same line like `if (a == b) {` and have a space directly to the left of the brace. Statements before the brace should be spaced as well, such as `for (int i = 0; i < n; ++i) {`
|
||||
- Separate multiple operations on the same line with a comma like `a = b, c = d;` or split them into different lines and use semicolons.
|
||||
- Use `++x` rather than `x++` to increment a variable (ie. in a `for` loop).
|
||||
- Start your `else` statement on the same line as the closing brace of your `if` statement, like so:
|
||||
|
||||
```cpp
|
||||
if(a == b){
|
||||
if (a == b) {
|
||||
++a;
|
||||
} else{
|
||||
++b;
|
||||
}
|
||||
```
|
||||
</li>
|
||||
<li>
|
||||
Binary operators should be spaced on both sides. For example, `a+b` should be written as `a + b` and `x=a+b` should be written as `x = a + b`.
|
||||
</li>
|
||||
<li>
|
||||
Unary operators can be not spaced or spaced on the left side, such as `x--` and `x = -y`.
|
||||
</li>
|
||||
<li> Use make_pair rather than {} to store a pair. </li>
|
||||
<li> Use `using namespace std` rather than `std::`. </li>
|
||||
<li> Use `struct` instead of `class`. </li>
|
||||
<li> Use `auto` when dealing with structs or iterators. </li>
|
||||
<li> Use `true / false` for boolean values, not `1 / 0`. </li>
|
||||
<li> Even if you are copy pasting a `struct`, space it out rather than squeezing it into one line. </li>
|
||||
<li>
|
||||
Write custom comparators using a comparison function.
|
||||
<!-- Any preferences? Also, this doesn't apply to the custom sorting module, make sure to include all 3! :) -->
|
||||
</li>
|
||||
<li>
|
||||
Explain the use of any not well known standard library functions with comments that haven't been introduced before like `__builtin_ffs()` or `tie(a, b, c)`.
|
||||
</li>
|
||||
<li>
|
||||
There should not be any extra spaces at the end of each line.
|
||||
</li>
|
||||
<li>
|
||||
Capitalize **Types with UpperCamelCase** (`SegTree, Point`), **functions with lowerCamelCase or lowercase** (`solve(), binarySearch()`) and **constants fully capitalized** (`INF, MOD, SOME_CONST`).
|
||||
</li>
|
||||
<li>
|
||||
Use `const` for variables that don't change through the code.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
- Binary operators should be spaced on both sides. For example, `a+b` should be written as `a + b` and `x=a+b` should be written as `x = a + b`.
|
||||
- Unary operators should only be spaced on the left side, ex. `x = -y`.
|
||||
- Use `make_pair` rather than `{}` to store a pair.
|
||||
- Use `auto` when dealing with iterators.
|
||||
- Use `true / false` for boolean values, not `1 / 0`.
|
||||
- Use `struct` instead of `class`.
|
||||
- Even if you are copy pasting a `struct`, space it out rather than squeezing it into one line.
|
||||
- Explain the use of any not well known standard library functions with comments that haven't been introduced before like `__builtin_ffs()` or `tie(a, b, c)`.
|
||||
- There should not be any extra spaces at the end of each line.
|
||||
- Use `const` for variables that don't change through the code.
|
||||
- Capitalize **Types with UpperCamelCase** (`SegTree, Point`), **functions with lowerCamelCase or lowercase** (`solve(), binarySearch()`) and **constants fully capitalized** (`INF, MOD, SOME_CONST`).
|
||||
|
||||
### Java
|
||||
|
||||
|
|
|
|||
Reference in a new issue