Created "recursion" for COP 3502C

[JacobGa03]

Created some tutorials for the basics of recursion. I created a folder and added the .md files to the "cs1" folder. I also added the tutorials to the index.md too.

Thanks.

[jerrettl]

Hey Jacob!! Really nice work with all of this. I think these are pretty comprehensive as far as things go. Since most of the content itself I think is pretty clear, most of the comments I have will be logistics.

(I should note that I tend to be pretty picky, but only because I look at this as a full "product" that we are building. I aim to set students up for the best advantage they can get, which usually just comes down to consistency. I also tend to check grammar and spelling more than your usual code submission since the focus is on writing and explaining things. Any comments I make are purely on the work itself, and nothing on you as an author. It is a lot but I'm always happy to hear your thoughts!)

Also since there are changes in multiple PRs, the comments related to contribution standards will be mostly here, but if anything comes up on the others, I will edit the list here. (The other PR comments will be MUCH shorter.)

I have some overall thoughts and some specific things to take a look at first, then the rest is all stuff that will need to be ironed out for the sake of creating a contribution standard. (So this will be a bit longer as the guinea pig!) Linting will help with this a ton as well.

There will also be some other small comments for very very small things, most of which are subjective.

Comments in no specific order:

• Again, really nice work! I think these explanations are pretty well-described. I really like that you went through this by "building up" the factorial example, which shows why we have certain structures and patterns in place for recursion. There is really not much substantial I need to say on your PR overall.
• I notice that sometimes "Factorial" is used with the capital, and sometimes lowercase. Factorial is not a proper noun, so I wanted to check if there was intent for using this? Otherwise lowercase would be closer to how English prose is written.
• The structure of headings might just want to be looked at for the "Recursion Basics" page, since right now it looks like everything is inside the introduction section. So maybe for example the conclusion, or additional resources would be a level 1 heading. I do see you already do this in other PRs, so more of just a consistency thing.
• I have still been struggling with thinking about the best way to do this, but with the links included in the pages, I am weary of the "evergreen content" guideline. To be clear, I love adding the extra links to other resources!! This is really good! I have always also been cautious of adding links to outside pages due to the potential maintenance factor that comes with it if a link ever has to change. I did make an extra credits page to start getting on this, but I'm open to thoughts on how to approach this. This would be part of contributor guidelines as well.
  • That said, I completely want to make sure all the credit and extra resources are there as needed. Maybe you can give the credits to Dr. Guha, but refer to the link outside the main content page? We can add the extra credits page to the site footer to keep it separate from any page too.
  • While I'm not sure how much that is the case now with the greater use of <details> tags these days, but the idea is that this could also export to PDF and be printed for personal notes. Of course you can't click a link on a piece of paper, but you can just omit the footer at the bottom on PDF export (which is what is done deep down in our PDF export template).

Contributor guidelines to consider:

• How should titles be capitalized? This is another thing that can be handled with a linter. Some examples of these standards are with the Associated Press or APA.
• Some grammar and spelling rules should apply, so for example using the full (non-abbreviated) forms of terms where possible for clarity (unless it has already been mentioned previously on the page) and ending all sentences with punctuation.
• The names of the entries within the main table of contents (like the CS1 page) should match the titles of each respective page. It is a small thing, and you can choose either way, but this should be consistent, whichever title you choose.
• Space vs. tab indentation: The Markdown format specifies to use spaces for indentation. (There is no issue with this here, but writing it for reference.)
• In code blocks, should there be a space between the tick marks and the language name? This should be based on whatever the linter says. At least in this PR's case, there is some inconsistency, but I will consider this part of the linting discussion.
• How should we do numbering? Numbering in Markdown has typically been done with "1.", "2."... and so on, and "#." as special for magic numbering.
• We need a standard for code formatting specifically.
  • I'm mostly leaning towards the CS50 Style Guide for C, as a lot of inspiration for this project came from them and I think they're the most sensible. That said, the GNU Coding Standards or the Linux kernel coding style are other possible contenders. Definitely open to thoughts!
  • This also includes code indentation standards. (2 spaces, 4 spaces, etc.)
• Markdown should have a newline before any heading. (Some interpreters will have a weird time with this otherwise. I have unfortunately learned this from experience...)
• The name of the organization is "Wiki Knights". (Even our leadership has gotten this wrong from time to time, but that is the de-facto way to write it.)
• We are Americans (YEEHAW 🦅🏈🏈🤠🇺🇸) so we should specify American English spelling. (This article uses American English spelling, and I didn't notice any misspellings using that as a base.)
• Along with the evergreen guidelines, I have also considered this being "course-agnostic," meaning the pages with actual explanations don't refer to any one specific course, like COP 3223 or Introduction to C Programming. While we do have that within our main page organization and folder structure, I think the pages themselves should be completely self-enclosed.
• Where should we place questions/answers in practice problem pages? Should they be combined alongside the questions using <details>, or should they be on a separate page? I see you have them merged in your practice problems page. Originally, we've had solutions exclusively in a separate page, since we used this for classes and had the questions provided but didn't give the solutions right away. But this is another old aspect of the project that was never really defined.
• C specific: Use of scanf(), printf(), gets(), etc. for input and output. This is one of those parts of C programming that is always going to differ depending on who you ask. Generally, we use a certain set of patterns at UCF for working with strings, so we can just specify that.

The rest are all specific to parts of the code outlined as follows:

[jerrettl]

I really like this video's visual style! 3Blue1Brown's graphics library is killer.

[JacobGa03]

When linking things like videos, articles, etc., should we just put the title of the media we are linking? Or should we add some additional info like "Creator X's video "(insert video title)".

[JacobGa03]

For the markdown linting I am using markdownlint as a VSCode extension. I do believe there is a CLI one can install to do a similar sort of thing for the giga-chads using Vim/NVim etc...