From e870c69be94de40491e858450fbb425d42b7c233 Mon Sep 17 00:00:00 2001
From: Benjamin Qi <bqi343@gmail.com>
Date: Thu, 16 Jul 2020 12:37:52 -0400
Subject: [PATCH] make modules compile

---
 content/1_Intro/Input_Output.mdx |  5 --
 content/1_Intro/Modules.mdx      | 84 +++++++++++---------------------
 2 files changed, 29 insertions(+), 60 deletions(-)

diff --git a/content/1_Intro/Input_Output.mdx b/content/1_Intro/Input_Output.mdx
index caf53f5..c8f03bd 100644
--- a/content/1_Intro/Input_Output.mdx
+++ b/content/1_Intro/Input_Output.mdx
@@ -58,11 +58,6 @@ For all subsequent modules, `#include <bits/stdc++.h>` will be used in place of
 
 </CPPSection>
 
-<JavaSection>
-
-
-
-</JavaSection>
 
 </LanguageSection>
 
diff --git a/content/1_Intro/Modules.mdx b/content/1_Intro/Modules.mdx
index 79a73c0..df6f729 100644
--- a/content/1_Intro/Modules.mdx
+++ b/content/1_Intro/Modules.mdx
@@ -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