shortening code? "Minification for humans" code Inventory ~ little code Study / Audit / "Obsessive compulsive reduction of unnecessary chars read by developers"

[ImprovedTube]

• this is inspiring, I bet i'm also reinventing the wheel in a number of ways? Let me know more automated ways
  • Also 🤔💡 could run 'longest common substrings' analysis on a project / repo, etc....

how many lines in the repo match ____ .... ?

• 94 x addEventListener vs. 45 x removeEventListener (=maybe should be more than 45) 19x stopPropagation 17x preventDefault

• 584 x function vs. 8 x => 200 x return 141 x target 75 x new

counted through: echo addEventListener | { read this; grep -riIPo "$this" | wc -l | { read count; echo $count x $this;}; } (grep with --include='*.js' maybe .. )

• Anything to (regex-)search&replace in our repo? @dodieboy 👋 @MohamedLebda

"efficient" :

VS. "many characters / waste of unintentional perception" variable declaration can be like a table of contents. Could/Should use a "JS alphabet" of abbreviations like d=document, w=window, (unless Youtube uses any differenly) ....

32 x mutation 13 x observe 38 x toggle 38 x change 8 x sync 77 x match 88 x | 51 x test 24 x regex 539 x : 486x [ 61 x array 25 x query[^s] 135 x message 73 x input 67 x string 135 x || 241 x && 153 x for 99 x ? 5 x while 21 x console.log ( there could be more console logging, despite it is slow, without removing it when building log = (x) => true; //uncomment for more logging: //log = (x) => console.log(x); )

6406 x . 3577 x ( 3377 x = 2730 x ; 1764 x { 1474 x , 971 x play (+ 2889x in .json) ( 707 x player ) 613 x improvedtube 948 x satus 417 x component 697 x element 679 x window 303 x document 445 x event 380 x storage 294 x video 288 x animation 267 x skeleton 176 x option 238 x http 200 x href 225 x browser 101 x chrome 94 x web 274 x parent 250 x child 221 x node 309 x value 170 x text 167 x type 196 x title 174 x style 157 x color 120 x date

• CSS: 1142 x , 966 x = 735 x it- 628 x [
  3763 x : 3420 x ;
  ...and 114 x querySelector( 42 x remove(|removeAttribue( (can/should these be reduced?)

• JSON language files: 1263656 characters, 41230 x : 41187 x " 20594 x { 20877 x ,
  the most covenient text-format for translators will be? :
  #englishMessage
  translation#englishMessage
  translation#englishMessage
  (sorted by 1. untranslated 2. recent. So that it will be fastest to translation & translation tools will stay unnecessary.)

---

• Yet we got: 911 x if ( , 301 x else
  ~149 IF's stand alone,
  ~373 IF's have a parent & no child
  ~226 IF's have a grandparent & no child,
  ~105 IF's have a greatgrandparent & no child
  ~57 IF's have a greatgreatgrandparent & no child

---

( the nested code was counted quickly as:
761 x 2nd level if ( inside another if ( before any }
388 x if ( inside another if ( before any } inside another if ( still before any}
162 x "if ( inside another if ( before any }"³
57 x "if ( inside another if ( before any }"⁴

grep -riIPo "\Wif\s+\(" --include='*.js' | wc -l
grep -riIPzo "\Wif\s+\([^\}]+\Wif\s+\(" --include='*.js' | wc -l
grep -riIPzo "\Wif\s+\([^\}]+\Wif\s+\([^\}]+\Wif\s+\(" --include='*.js' | wc -l
grep -riIPzo "\Wif\s+\([^\}]+\Wif\s+\([^\}]+\Wif\s+\([^\}]+\Wif\s+\(" --include='*.js' | wc -l
grep -riIPzo "\Wif\s+\([^\}]+\Wif\s+\([^\}]+\Wif\s+\([^\}]+\Wif\s+\([^\}]+\Wif\s+\(" --include='*.js' | wc -l

)

[ImprovedTube]

just a SideNote / "FAQ"
Nested code:

JS "top dog" syntax	"challenger"
if(a){A();A2; if(b){B(); if(c){C();}else{alternativeC();}} else{alternativeB()}} else{alternativeA()};	a?(A(),A2() b?(B() c?C():alternativeC()) :alternativeB()) :alternativeA();

"Why isn't the 'challenger' popular?"

• convention & readability
• bad: requires to use : (else), even when there's nothing else to do
• good: { } could stay reserved to inicate relevance, the fact or prediction, that they will span more than a screen full, or that they are greatgrandparents of other "IF"'s. While reading a ? could indicate you dont need to review this line. Its done. Minified. More architectural information, Fewer characters.
• Neutral: Developers can be expected to care for details such as using , instead of ; or if some don't, that might be an easy/automatable indicator for carelessness (while checking PRs etc.)

Conclusion: It is ok, if we keep the short IF only inline (no grandchildren) and only if "else" is wanted. Unnecessary to have variants. I.e. if you can (ever) predict your if, will stay "childless", then you can show that through saving the { } character. Yet while such predictions may be good, they don't require this way (can also be through comments in the code.)

[raszpl]

"many characters / waste

dont worry about any of this, javascript is fetched from the server automagically compressed https://en.wikipedia.org/wiki/HTTP_compression forgot we are talking about extension :) still even the smallest extension possible takes ~30MB of ram in Chrome, and this one is only ~2MB, nothing to worry about.

why isnt the 'challenger' popular?

its unreadable, write once code. Two levels deep is already super annoying to read, 3 levels is waste of time figuring out what the last guy did here.

[ImprovedTube]

"minification for humans?"
"many characters / waste of unintentional perception"

About human perception, saving developer's time. @raszpl

still even the smallest extension possible takes ~30MB of ram in Chrome, and this one is only ~2MB, nothing to worry about.

Still good to mention (first in this Repo!)

unreadable ... 3 levels

Yes, just compulsively applying the title "minification for humans", since the majority of our "IF"'s is short with no grandparent,
just to make an example what might be worth thinking about.

---

What about this though ? :

Code-Scroll-Height-Reduction:
"Pre-folded by the author" (Squeezing lots of code into single lines)

Given the prediction, that a snippet of code will mostlikely never change or never need to be read,
then
removing line breaks will reduce scroll-heights, improving focus & speed.

IDEs could wrap/format those 'mega lines' conditionally anyway only when deepest nested code / indents are also unfolded.

[ImprovedTube]

why even camelize anything?

• Typing less (saving people from typing _'s underScores).
  

  • especially "if (camelized_key === 'playerForcedPlaybackSpeed')" looks unnecessary?

• 🤔 convention to welcome the average [JS-]developer
  
  
  

  • Didnt prove other advantages/disadvantages of camelCases yet.
    (doesn't sound like an answer:) "those trained in camel casing are able to recognize identifiers in the camel case style faster than identifiers in the underscore style. cs.loyola.edu/~binkley/papers/..." (https://dev.to/reedbarger/how-javascript-variables-should-be-named-13hm)

  • camelCase' relevance seems to mostly always grow globally
    
    
    
    trends.google/camelCase,snake case,underScore,pascal case,kebab case&date=all
    
    & in JS too: js camelCase,js underScore,javaScript camelCase,javaScript underScore

[ShalokShalom]

Sorry, in case you try to draw a conclusion based on these search terms, to figure out how popular they are:

First, underScore is literally the first time I heard or read anyone calling that.

Its snake case, generally.

And secondly, and most importantly, is nobody googling its favorite case style.
Like, why would anyone do that?

People use what is the convention of the language 90% of the time.
Other than that, they use what they prefer.

I prefer snake case and kebab case, cause its easier to read.
Code should be optimized to be readable. Since we read much more than we write.

Peter Seibel, in his book "Coders at Work," interviewed several renowned programmers who emphasized the importance of reading code. Douglas Crockford, for example, stated, "Reading code is much harder than writing it." This sentiment is shared by many experienced developers.

An article published by Jeff Atwood, co-founder of Stack Overflow, titled "Code: Readability Counts," discusses the significance of code readability. Atwood argues that code is read by many people throughout its lifecycle, including the original author, colleagues, maintainers, and future developers. Therefore, writing readable code is crucial for effective collaboration and long-term maintainability.

The concept of "code reviews" is widely practiced in software development. Code reviews involve developers reading and reviewing each other's code to identify bugs, improve quality, and share knowledge. This process highlights the importance of reading code as a significant part of the development workflow.

https://www.goodreads.com/quotes/835238-indeed-the-ratio-of-time-spent-reading-versus-writing-is

[ImprovedTube]

nobody googling its favorite case style.
Like, why would anyone do that?

yes! @ShalokShalom a method needs not to be flawless when mentioned 4th in 4 quick associations.
there might generally be some bi-directional correlation between practice, curiosity, research, actual practice, publishing, 'best-practices' & official standards.

to update the first point:

prevItem language:JavaScript sais 27.3k results now!
prev_item language:JavaScript only made it to 908
prev_item lists 45.4k now tho.

Supports the fact that JS is set on camelCase, while all other languages combined prefer snake case.
(Besides if i use -language:JavaScript (exclude Javascript, the numbers prove inaccurate / estimates.)

First, underScore is literally the first time I heard or read anyone calling that.

yes, adding it:

trends.google/camelCase,snake case,underScore,pascal case,kebab case&date=all

(so snake case became searched as a word later in history, yet might grows a bit faster than camelCase. Yet, to be fair we need to include "camel case" so combining the spellings it is double. While kebab case started even later, so it could also catch up.)

And it might be relevant linguistically for us to acknowledge the overall weight of a word, like "underscore". Since most people & developers learn English first.

Since part of this project doesn't require much specialization and developers often are learning by doing or as autodidacts. https://trends.google.com/trends/explore?date=today%205-y&q=camelCase%20variables,underscore%20variables,snake%20case%20variables,underscore%20name,pascal%20case And most people didn't chose JS for it's apparent naming convention either but since their was no alternative 🤔

Also camelCase has a problem as URLs and usernames generally ignore case. - Something most people might know and apply since before they start programming, even if subconsciously

[ImprovedTube]

... readability ...

yes! agree for variables names
vs. (said above) irrelevant stuff should be short == efficient, "minification for humans"

• shortening the variable name ImprovedTube can make our 400kb for features 1.5% shorter

• if i can predict something is very unlikely to be edited i really want to squeeze it in one line to possibly warn the reader to focus on the wrong part🤔.

• local variables inside a function, often are very specific/irrelevant (like for i in range). So contributors need not use descriptive names but they can be short & consistent with the global standard if there is one. (since coders are good /tolerant with abstraction(/math/playing new "board games" or different ones at the same time.)

• replaced {display: none} with , in this file many times https://github.com/code-charity/youtube/blob/master/js%26css/extension/www.youtube.com/appearance/details/details.css

  • tempted to continue for the whole repo and have a file called hide.css.
    • while this idea might sound bad from the current structure's perspective, and this idea can be found simply through searching for longest common sub-string (even without knowing the project). and is no dead-end road (ideally one could dynamically keep different structures at once). And in this case, while this file hide.css is only a few % of our work, it is more of the maintenance and they might belong in the same list in our UI too. They might be maintained/updated all in a row
    • like Unhook, (a project thats X times younger? - it has more users than ImprovedTube, with mostly only "display:none features" ) so obviously as a consquence of having a similar .css file, both projects would be set to sharing that work to have more updates with less human effort. ( #1881 / @alisonch )

[ImprovedTube]

the (verbose 2000) lines

..*in themes.css lines including only variables appear 6 times (like --yt-searchbox-text-color: var(--yt-primary-text-color);) and thus could be summed up in one block for all themes.

• (duplicate lines can be spotted using linux cat themes.css | uniq -cd | sort -nr ....)
• shortening code? "Minification for humans" code Inventory ~ little code Study / Audit / "Obsessive compulsive reduction of unnecessary chars read by developers" #1634

( #1787 (comment) )

[ImprovedTube]

on css performance:

If you are worried about performance look into all very slow CSS rules used for theming. All the ones with wildcards are very expensive. Throwing CSS files into http://csslint.net/ will give you hints on what to look for.

(from #2073)