My team uses C++. The way I teach it is pretty tightly integrated with the software engineering principles I try to impart and the actual applications in FRC. I do that because it’s a lot easier to get students through the syntactic gotchas of C++ if they have interesting applications to work on. I think how you use the language at hand to solve FRC problems is more important than just learning a new language, so having context for how the learning resources fit into the overall pedagogy is important.
Note that a lot of the feedback portions require a dedicated software mentor, so this regimen may not work for everyone.
To teach my students C++, I use the book Programming: Principles and Practice Using C++ (2nd edition) by Bjarne Stroustrup. I like it because it’s designed for independent learning, works well for teaching students programming from scratch, and covers modern C++ idioms. A lot of the C++ resources I see online don’t follow best practices. By the way, those best practices are here: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.
With regard to memory management, try to think about ownership in terms of “who cleans this up when I’m done with it?”. The short version is don’t use the new and delete keywords for anything; prefer stack variables; if you need something on the heap, use std::unique_ptr for sole ownership; and use std::shared_ptr for shared ownership. I rarely use std::shared_ptr in my experience because a lot of ownership scenarios don’t represent true shared ownership. They are either a stack variable with only one object looking at it or a std::unique_ptr with a non-owning pointer to it somewhere else.
The online resources I put together for my students are here: https://csweb.frc3512.com/ci/cs01/. I usually walk them through a chapter per week, then they do the exercises and I provide implementation and style feedback on their solutions. They make any corrections, and then we move on. This introduces them to the concept of code review.
At the same time, I give them a lecture on Git (the HTML slides I use on at https://csweb.frc3512.com/ci/git01/, and I have my students submit the solutions mentioned earlier via Git. I try to emphasize how Git is basically an application of graph theory, because having that deeper understanding has saved our butts a couple times at competition when my students start doing hairy things to the branches and history.
One of my students even dug into the reflog at one point to get back some old commits because he wasn’t following good branching hygeine, but the fact he was able to recover himself is a testament to how flexible Git is when you really understand it. I try to teach my students enough to avoid https://xkcd.com/1597/ at all costs, because you should never need to abort and do a fresh clone.
We use Gerrit for code review because I like the rebase workflow better than the merge workflow of GitHub (and we enforce rebases through the admin interface). I cover more of how to do that stuff in the presentation at https://csweb.frc3512.com/ci/git02/. I still need to go through those and expand on the lecture notes.
As far as branch hygeine, you keep master as the working version and give branches descriptive names and commit messages (no "Fixes " branch and also “Fixes the issue for real, I promise” with no indication as to which is the real “working” branch). A big part of in code review contexts is maintaining a clean commit history. I despise merge commits for this reason; they are just noise (last I checked, Brad was tied for most commits in wpilibc/wpilibj if you include the huge number of merge commits). Just rebase against master since you’re doing that merging work either way and you get cleaner history with a rebase. Rebasing a PR on GitHub or a changeset on Gerrit is technically modifying public history, but we treat those branches as private so the author can rebase it to produce a branch that is easier to review.
After we cover most of the C++ material, we move into doing state machines, starting with a lecture on what that is (https://csweb.frc3512.com/ci/frc01/) and then designing an auto-stacking state machine for our 2015 robot together https://csweb.frc3512.com/ci/frc01/state-machine/. Once we finish the state machine diagram, the students fill in the template provided with their state machine logic. I review it and test it against my working copy. I’ll probably integrate Google Test into this at some point, because unit testing is a skill I want to start teaching in FRC as well.
Basically, the idea is the students work on mini-projects to learn skills, then they put it all together during competition season. We spend probably a month during offseason teaching new members. Things go faster if the student does the assignments on their own time because the software team usually gets pulled away during the offseason build sessions for FLL things.
We usually don’t get to https://csweb.frc3512.com/ci/frc02/ until build season, which teaches common design patterns using WPILib classes. I try to provide project templates with stuff like a .clang-format file so they can start off with good practices by default. We use the first part of build season to do more robot-specific training with C++ like drive code, subsystem abstraction design, incorporating feedback controllers, and tuning them.