Merge branch 'main' into add-codeql-support

.vscode/extensions.json

@@ -8,10 +8,6 @@
     // https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack
     "vscjava.vscode-java-pack",
 
-    // EditorConfig for VS Code
-    // https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig
-    "EditorConfig.EditorConfig",
-
     // Gradle language support
     // https://marketplace.visualstudio.com/items?itemName=naco-siren.gradle-language
     "naco-siren.gradle-language",
@@ -22,7 +18,20 @@
 
     // GitHub Markdown Preview
     // https://marketplace.visualstudio.com/items?itemName=bierner.github-markdown-preview
-    "bierner.github-markdown-preview"
+    "bierner.github-markdown-preview",
+
+    // Support GitHub Markdown emoji syntax
+    // https://marketplace.visualstudio.com/items?itemName=bierner.markdown-emoji
+    "bierner.markdown-emoji",
+
+    // Support footnotes in GitHub Markdown
+    // https://marketplace.visualstudio.com/items?itemName=bierner.markdown-footnotes
+    "bierner.markdown-footnotes",
+
+    // Support Markdown linting, which also provides the default formatting for
+    // Markdown files.
+    // https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint
+    "davidanson.vscode-markdownlint"
   ],
   // List of extensions recommended by VS Code that should not be recommended for users of this workspace.
   "unwantedRecommendations": []

.vscode/settings.json

@@ -1,14 +1,42 @@
 {
-    "java.configuration.updateBuildConfiguration": "automatic",
-    "java.server.launchMode": "Standard",
-    "cSpell.words": [
-        "gaurav",
-        "wizarding"
-    ],
-    "files.exclude": {
-        "**/.classpath": true,
-        "**/.project": true,
-        "**/.settings": true,
-        "**/.factorypath": true
-    }
-}
+  "cSpell.words": [
+    "automagically",
+    "bangbang",
+    "gaurav",
+    "gradlew",
+    "Phee",
+    "unstage",
+    "Unstaged",
+    "wizarding"
+  ],
+  "editor.formatOnSave": true,
+  "[java]": {
+    "editor.suggest.snippetsPreventQuickSuggestions": false,
+    "editor.defaultFormatter": "redhat.java",
+  },
+  "[markdown]": {
+    // Prettier tends to mangle Markdown, so we'll use the Markdownlint extension instead.
+    "editor.defaultFormatter": "DavidAnson.vscode-markdownlint",
+    "editor.unicodeHighlight.ambiguousCharacters": false,
+    "editor.unicodeHighlight.invisibleCharacters": false,
+    "diffEditor.ignoreTrimWhitespace": false,
+    "editor.wordWrap": "on",
+    "editor.quickSuggestions": {
+      "comments": "off",
+      "strings": "off",
+      "other": "off"
+    },
+    "cSpell.fixSpellingWithRenameProvider": true,
+    "cSpell.advanced.feature.useReferenceProviderWithRename": true,
+    "cSpell.advanced.feature.useReferenceProviderRemove": "/^#+\\s/"
+  },
+  "editor.formatOnSaveMode": "file",
+  "java.configuration.updateBuildConfiguration": "automatic",
+  "java.server.launchMode": "Standard",
+  "files.exclude": {
+    "**/.classpath": true,
+    "**/.project": true,
+    "**/.settings": true,
+    "**/.factorypath": true
+  }
+}

PART_1_SHARE_INFO.md

@@ -42,12 +42,12 @@ will create a copy on GitHub for your team of our starter
 repository; your team will use that as the starting point for your work.
 
 This lab is unusual in that we will all be on a single large team called
-__Everyone__, all making changes to a single shared repository. This will
+**Everyone**, all making changes to a single shared repository. This will
 help illustrate the value of version control systems like `git` in managing
 this kind of shared resource, and also give us opportunities to see what
 happens when different people make inconsistent changes to the same files.
 
-So follow the link in the Canvas assignment and join the __Everyone__ team;
+So follow the link in the Canvas assignment and join the **Everyone** team;
 that should take you to the shared repository on GitHub. From there
 you can get the URL for that repository
 from the green `Code` button visible on the "home page" for each

PART_2_JAVA_INTRODUCTIONS.md

@@ -64,8 +64,7 @@ GitHub account** as this will do two important things:
   GitHub Student Pack, you should do so before setting up GitKraken._
 
 After you've authenticated with GitHub, GitKraken will ask to setup
-your `git` info ([like you did at the start for the command line](#configuring-your-git-e-mail));
-you should enter your name and whatever email you've used for GitHub.
+your `git` info; you should enter your name and whatever email you've used for GitHub.
 
 Once all the setup is finished, select `File -> Open` and navigate to the directory
 containing your local clone (`intro-to-git`), and open that up. There's a lot of information
@@ -426,9 +425,8 @@ and project repositories in this course. All those checks have to pass before
 you can merge in your pull request. For this lab we have four checks:
 
 - "build": This runs `./gradlew check`, which compiles the code
+  and runs the JUnit tests. If these succeed you get a green check mark, and you get a red x if anything fails.
   and runs several checks. If all of these succeed you get a check mark (:white_check_mark:), and you get a red x (:x:) if anything fails.
-  - It uses a tool called [Checkstyle](https://checkstyle.org/) that
-    checks that your code follows a set of basic style guides.
   - It runs the JUnit tests
   - It confirms that the test coverage is at least 80%. (This should
     be trivially true as the tests that we've provided should
@@ -449,18 +447,13 @@ are. :bangbang: That's one of several reasons you should usually run the tests l
 you push.
 
 If any of the checks fail (give you a red :x:), then you probably want to click on
-"Details" by that check to learn more about what might have failed.
-
-- If the Java `build` fails, it's likely because a test has
-  failed, either because you didn't structure your
-  greeting correctly, or you didn't put it in the correct place so that all
-  greetings are in alphabetical order. You should probably run the tests again
-  on your computer, where you'll get more information on which test failed and
-  why. If you're unsure how to proceed _definitely ask for some help!_
-- The other way the Java `build` could fail is if your formatting
-  doesn't meet the Checkstyle criteria. Run `./gradlew check`
-  locally and see if the output there helps you understand
-  why things are failing.
+"Details" by that check to learn more about what might have failed. If the
+Java `build` fails, it's likely because a test has
+failed, either because you didn't structure your
+greeting correctly, or you didn't put it in the correct place so that all
+greetings are in alphabetical order. You should probably run the tests again
+on your computer, where you'll get more information on which test failed and
+why. If you're unsure how to proceed _definitely ask for some help!_
 
 #### You might need to merge in changes from `main`
 
@@ -496,7 +489,7 @@ Here, if Chris clicks the "Resolve conflicts" button, GitHub will put Chris in
 a (web) editor where they can resolve the conflicts. That editor will likely
 have a section that looks something like:
 
-```java
+```diff
  <<<<<<< chris-greeting
     builder.append(chrisSaysHello());
  =======
@@ -596,10 +589,10 @@ look over the code and make sure the changes look reasonable. Some things to
 check for:
 
 - [ ] Does it look (by eye) that this will print all the greetings in alphabetical
-  order? (The tests check that for sure, but you should always be thinking about
-  correctness as well.)
+      order? (The tests check that for sure, but you should always be thinking about
+      correctness as well.)
 - [ ] Do the new methods they're adding have reasonable names that convey useful
-  info to the reader?
+      info to the reader?
 - [ ] Are new method names in camel cases, starting in lowercase (the Java standard
   for method names)?
 - [ ] Is the implementation of the new methods reasonable?

README.md

@@ -9,12 +9,12 @@
 >
 > - [ ] Create a team called "Everyone"
 > - [ ] Fix the URLs in the badges below so they point to that semester's
->     repository instead of the "starter" repo.
+>       repository instead of the "starter" repo.
 > - [ ] Make sure we've added every student in the current semester
->     to that semester's organization so they'll have permission to
->     push to this repo.
+>       to that semester's organization so they'll have permission to
+>       push to this repo.
 > - [ ] [Turn off branch protection](docs/FACULTY_BRANCH_PROTECTION_SETTINGS.md)
->     so that students can `push`.
+>       so that students can `push`.
 > - [ ] Remove this note and the broken badge above in the fork.
 >
 > We should leave these notes in the copy in the "starter"
@@ -88,9 +88,9 @@ its more advanced features.
 
 - The excellent [Atlassian `git` tutorials](https://www.atlassian.com/git/tutorials/what-is-version-control)
 - [The "standard" `git` documentation site](https://git-scm.com/documentation),
-which also includes links to videos, cheat sheets, and such
+  which also includes links to videos, cheat sheets, and such
 - [`git` – the simple guide](http://rogerdudler.github.io/git-guide/),
-a single-page app that goes through the major features of `git`
+  a single-page app that goes through the major features of `git`
 - [A little on-line "game" for learning how branching works in `git`](https://learngitbranching.js.org/)
 
 As circumstances allow, you might also want to at least skim one or two of the

build.gradle

@@ -11,10 +11,6 @@ plugins {
 
   // Apply the Jacoco plugin to add suppport for JUnit test coverage reports.
   id 'jacoco'
-
-  // The checkstyle plugin provides basic Java style checks to ensure we're
-  // following industry style standards.
-  id 'checkstyle'
 }
 
 // In this section you declare where to find the dependencies of your project.