Unstable

[Michael-wang98]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly
• Put an x into all the boxes [ ] relevant to your pull request (like that [x])
• Use Preview tab to see how your pull request will actually look like

---

Before submitting a pull request make sure you have:

• [x] Searched the bugtracker for similar pull requests
• [x] Read ytmdl coding conventions and adjusted the code to meet them
• [ ] Checked the code with pylama
• [x] Made the pull request to the unstable branch

What is the purpose of your pull request?

• [ ] Bug fix
• [x] Improvement
• [ ] New feature

---

Description of your pull request and other information

Assorted (non-code) grammatical and syntax fixes throughout the codebase to things like inline and block comments as well as the README and the help dialogue to clean up the non-code stuff. The main things implemented were:

• Fixed typos E.G. usefull -> useful or "For eg:" (which would mean "for example given") -> "E.G." (example given)

• Standardized capitalization and punctuation for block comments: sometimes a block comment ends with a period sometimes it doesn't, sometimes it begins on a capital letter sometimes it didn't. Standardized it so all sentences in block comments end with a period E.G. """add the passed song to the archive file""" -> """Add the passed song to the archive file."""

• Also made certain short block comments a single line instead of multiple

• Standardized punctuation for inline comments: sometimes inline comments end with a period sometimes they don't sometimes it begins on a capital letter sometimes it didn't. I tweaked it according to the rule "Inline comments begin with a capital letter and do not end in a period unless there is another inline comment that follows it" E.G. "# Read the values from the user." -> "# Read the values from the user"

• Standardized spelling for proper nouns: E.G. youtube -> Youtube and Itunes/itunes -> iTunes

• Tweaked some comment syntax to make it more readable E.G. "Check if choice if -2. If it is that, then we need to stop executing" -> "Check if choice is -2. If so, then we need to stop executing" or "# Below will be used to fetch extra data" -> "# The variable below will be used to fetch extra data"

• In the README retouched the Windows installation section to make it more streamlined, the original link to the FFMPEG downloads seems like a pain point since the user may download the tar ball not knowing it doesn't contain the .exe and that you basically need Linux to compile it (which wouldn't be intuitive to have in the Windows section). Just linked directly to the place to download the executable. Also added explicit notes about the Windows installation tools like Chocolatey and WinGet which would make it simpler to use

Cleaned up the help dialogue (changed are mirrored in main.py and the README)

• Standardized every help description to begin with a capital and end with a period E.G. show this help message and exit -> Show this help message and exit.
• Standardized the phasing for default values so there is no period before the bracket, there is a period after the bracket and the defaults all share a formatting E.G. "song. Default is false." -> "song (Default: false)." and "end at (default is last)" -> "end at (Default: last)."
• Assorted minor fixes for grammar, syntax and spelling

PS I did try linting with PyLama at the beginning and the end but it flags a ton of things even at baseline, its unclear which rules were even intended to be followed (and its hard to tell what linting flags are new) you might want to add a pylama config file in order to define how the code should be linted if a certain set of rules is intended

[deepjyoti30]

@Michael-wang98 Thanks for the PR. I was surprised to see all the changes you made as it would have taken you some time to go through all the code and make all those changes, or did you use some tool to achieve this?

Anyhow, thanks for the PR, appreciate the effort!

[Michael-wang98]

@deepjyoti30 I did just manually sift through the code, I know certain linters will automatically apply certain rules (E.G. ESLint for JS can automatically capitalize the first letter in every comment if you turn on that rule and run the linter) which would probably have sped things along (Pylama might do that but I didn't look into it because as noted there's a lot of stuff that Pylama flags even without changing anything) but I didn't initially anticipate that I'd look over so much of it. I initially just noticed the misspelled "usefull" in the help dialogue and the Windows section in the README which confused my friend when he tried to use it and then kinda confused me for a bit and then just randomly decided to start fixing comments.

This is a pretty nifty project you have here, keep up the good work