Code Quality (no-nonsense JS)

[4yman-0]

conflicts with #2462

[4yman-0]

A deicision has to be made about features/compatibility.
Use let and const or just var?
Use fancy for of and for in or for (var i = 0;...)?
Use if (!ok) return or (ok) => {if (ok){ ... }}?
Many people have contributed to this project. Without some sort of style guideline or Continous Intergration it had developed into spaghetti try catch timeout try catch code.

[ImprovedTube]

hi again and thanks! @4yman-0 - this must have taken a while!! Makes me hopeful you spend more hours here in future.

Most of the current code was still written and structured by the same author carefully, who is gone since 2022.

Architecture: #2415 (#2459) #2276

---

Use let and const or just var?

The majority of existing choices (main authors) will be for a reason. The random (some authors) might not matter.
We can use whats best and or shortest and define a guideline.
in 2024 @raszpl edited a lot and prepared/demonstrated much more linting at https://github.com/raszpl/tweaks4ytube
(not sure either if / when @raszpl will be back unfortunately)

into spaghetti try catch timeout try catch code.

Please note down if anything really seems complication, like slowing down development. I might added some quick remedies /tests without indentation or line breaks and (so they can be identified like that too. ) (So that's just work in progress and formatting these equally makes that less clear. Some of it might also be ok to stay for 20 years. who knows, as long as we have open issues and more important tasks than reducing nano seconds of cpu.)

Reducing code size:
RE: aacda82 sometimes the code checks if features are set true in storage, because false values were also stored not deleted (mostly needlessly) and few (seven?) feature are true by default too. Pending PR: https://github.com/code-charity/youtube/pull/2462/files )

Misc: We could shrink the code by some more percent #1634, for example most (all?) of the improvedtube.something() functions checking improvedtube.storage.something etc. could use "this" - if in all foreseeable future the functions need not be called differently changing "this".

[4yman-0]

into spaghetti try catch timeout try catch code.

Please note down if anything really seems complication, like slowing down development.

I don't really think that slowing down developement. TBH try catch timeout try catch can be formatted nicely and called error handling (for YTs frequent changes). It didn't appear out of thin air.

We can use whats best and or shortest and define a guideline.

here's CanIUse for ES6 (the kinda new javascipt) which the upstream (code-charity) code is already using (const let obj?.something). I'm sure if users really cared there would have been an issue long before this PR. HOWEVER it breaks satus (probably because of () => { this }) so I will not touch it.

Reducing code size:
RE: aacda82 sometimes the code checks if features are set true in storage, because false values were also stored not deleted (mostly needlessly) and few (seven?) feature are true by default too. Pending PR: https://github.com/code-charity/youtube/pull/2462/files )

Misc: We could shrink the code by some more percent #1634, for example most (all?) of the improvedtube.something() functions checking improvedtube.storage.something etc. could use "this" - if in all foreseeable future the functions need not be called differently changing "this".

This PR is called "Code Quality". I can work on a "Use BASH for CI and remove async loading" after this is resolved.

Edit: Add stuff.
Edit 2: See the comment below.
Edit 3: Elaborate on why satus did not work.

[4yman-0]

After a lot of trial and error. I will not use ES6 because it breaks satus

[ImBIOS]

I agree, but I hope we can add full coverage tests before doing this. To "have a prove" and be sure nothing is breaking.

[ImBIOS]

I agree, but I hope we can add full coverage tests before doing this. To "have a prove" and be sure nothing is breaking.

I changed my mind, I think having ESLint and Prettier rules applied to this repo is the first step. Then we can improve the tests later, because ESLint and Prettier should not interfere with the functionality of the code itself at all.

[ImBIOS]

I suggest to add ESLint and Prettier rules in the repo

[ImBIOS]

• Add ESLint and Prettier Rules Config Files #2724