BranchesTags

Repository files navigation

Code Principles

Hi All ❤️

There are a few of these principles that will be universally accepted, but not all of them must be completely adhered to. These are merely guidelines,
but ones that have been formalized over a long period of time.

One more thing: even if you have years of experience with them, knowing them won't make you a better software developer right away.
Like wet clay being molded into its final form, every line of code begins as a first draft.
When we review it with our colleagues/friends, we finally chisel out the flaws. Don't be hard on yourself if your early drafts need work. Instead, abuse the code!

Let's code our wisdom like a melodic poetry ❤️

To keep in mind:

  • Use type annotations to explicitly declare the types of variables, function arguments, and return values. This makes it clear to other developers (and to the TypeScript compiler) what the expected types are, and can help prevent type errors.

  • Use interfaces to define the shape of complex types, such as objects with multiple properties or arrays with specific elements. This can make your code more self-documenting and easier to understand.

  • Use classes and encapsulation to organize your code into logical units and protect the internal state of your objects from being modified by external code.

  • Follow the SOLID principles of object-oriented design to create code that is easy to understand, maintain, and extend.

DRY (Don't Repeat Yourself)

KISS (Keep it simple, stupid)

YAGNI (You ain't gonna need it)

Variables

Use meaningful variable names

Use pronounceable variable names

Use the same vocabulary for the same type of variable

Use searchable names

Use explanatory variables

Avoid Mental Mapping

Use default arguments instead of short circuiting or conditionals

Use enum to document the intent

Functions

Function callers and callees should be close

Function arguments (2 or fewer ideally)

Functions should do one thing

Function names should say what they do

Functions should only be one level of abstraction

Remove duplicate code

Set default objects with Object.assign or destructuring

Don't use flags as function parameters

Avoid Side Effects (part 1)

Avoid Side Effects (part 2)

Don't write to global functions

Favor functional programming over imperative programming

Encapsulate conditionals

Avoid negative conditionals

Avoid conditionals

Avoid type checking

Don't over-optimize

Remove dead code

Use iterators and generators

Objects and Data Structures

Use getters and setters

Make objects have private/protected members

Prefer immutability

type vs. interface

Classes

Classes should be small

High cohesion and low coupling

Prefer composition over inheritance

Use method chaining

SOLID

Single Responsibility Principle (SRP)

Open/Closed Principle (OCP)

Liskov Substitution Principle (LSP)

Interface Segregation Principle (ISP)

Dependency Inversion Principle (DIP)

Testing

Testing is more important than shipping. If you have no tests or an inadequate amount, then every time you ship code you won't be sure that you didn't break anything.
Deciding on what constitutes an adequate amount is up to your team, but having 100% coverage (all statements and branches)
is how you achieve very high confidence and developer peace of mind. This means that in addition to having a great testing framework, you also need to use a good coverage tool.

There's no excuse to not write tests. There are plenty of good JS test frameworks with typings support for TypeScript, so find one that your team prefers. When you find one that works for your team, then aim to always write tests for every new feature/module you introduce. If your preferred method is Test Driven Development (TDD), that is great, but the main point is to just make sure you are reaching your coverage goals before launching any feature, or refactoring an existing one.

The three laws of TDD

  1. You are not allowed to write any production code unless it is to make a failing unit test pass.

  2. You are not allowed to write any more of a unit test than is sufficient to fail, and; compilation failures are failures.

  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

F.I.R.S.T. rules

Single concept per test

The name of the test should reveal its intention

Concurrency

Prefer promises vs callbacks

Async/Await are even cleaner than Promises

Error Handling

Thrown errors are a good thing! They mean the runtime has successfully identified when something in your program has gone wrong and it's letting you know by stopping function

execution on the current stack, killing the process (in Node), and notifying you in the console with a stack trace.

Always use Error for throwing or rejecting

Don't ignore caught errors

Don't ignore rejected promises

Migrating from TSLint to ESLint

Code Organization

Use consistent capitalization

Organize imports

Use typescript aliases

Comments

The use of a comments is an indication of failure to express without them. Code should be the only source of truth.

Don’t comment bad code—rewrite it.

— Brian W. Kernighan and P. J. Plaugher

Prefer self explanatory code instead of comments

Don't leave commented out code in your codebase

Don't have journal comments

Avoid positional markers

TODO comments

About

A Reactjs coding style guide

linuxdevil.github.io/React-Style-Guide/

Topics

jsprinciplesreactreactjsstandardsstyle-guidestyleguidetypescript

Resources

Readme
Activity

Stars

7 stars

Watchers

1 watching

Forks

0 forks
Report repository

Contributors

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
BranchesTags
Repository files navigation
Code Principles
Hi All ❤️
There are a few of these principles that will be universally accepted, but not all of them must be completely adhered to. These are merely guidelines,

but ones that have been formalized over a long period of time.
One more thing: even if you have years of experience with them, knowing them won't make you a better software developer right away.

Like wet clay being molded into its final form, every line of code begins as a first draft.

When we review it with our colleagues/friends, we finally chisel out the flaws. Don't be hard on yourself if your early drafts need work. Instead, abuse the code!
Let's code our wisdom like a melodic poetry ❤️
To keep in mind:
  • Use type annotations to explicitly declare the types of variables, function arguments, and return values. This makes it clear to other developers (and to the TypeScript compiler) what the expected types are, and can help prevent type errors.
  • Use interfaces to define the shape of complex types, such as objects with multiple properties or arrays with specific elements. This can make your code more self-documenting and easier to understand.
  • Use classes and encapsulation to organize your code into logical units and protect the internal state of your objects from being modified by external code.
  • Follow the SOLID principles of object-oriented design to create code that is easy to understand, maintain, and extend.
DRY (Don't Repeat Yourself)
 KISS (Keep it simple, stupid)
YAGNI (You ain't gonna need it)
Variables
Use meaningful variable names
Use pronounceable variable names
Use the same vocabulary for the same type of variable
Use searchable names
Use explanatory variables
Avoid Mental Mapping
Use default arguments instead of short circuiting or conditionals
Use enum to document the intent
Functions
Function callers and callees should be close
Function arguments (2 or fewer ideally)
Functions should do one thing
Function names should say what they do
Functions should only be one level of abstraction
Remove duplicate code
Set default objects with Object.assign or destructuring
Don't use flags as function parameters
Avoid Side Effects (part 1)
Avoid Side Effects (part 2)
Don't write to global functions
Favor functional programming over imperative programming
Encapsulate conditionals
Avoid negative conditionals
Avoid conditionals
Avoid type checking
Don't over-optimize
Remove dead code
Use iterators and generators
Objects and Data Structures
Use getters and setters
Make objects have private/protected members
Prefer immutability
type vs. interface
Classes
Classes should be small
High cohesion and low coupling
Prefer composition over inheritance
Use method chaining
SOLID
Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)
Testing
Testing is more important than shipping. If you have no tests or an inadequate amount, then every time you ship code you won't be sure that you didn't break anything.

Deciding on what constitutes an adequate amount is up to your team, but having 100% coverage (all statements and branches)

is how you achieve very high confidence and developer peace of mind. This means that in addition to having a great testing framework, you also need to use a good coverage tool.
There's no excuse to not write tests. There are plenty of good JS test frameworks with typings support for TypeScript, so find one that your team prefers. When you find one that works for your team, then aim to always write tests for every new feature/module you introduce. If your preferred method is Test Driven Development (TDD), that is great, but the main point is to just make sure you are reaching your coverage goals before launching any feature, or refactoring an existing one.
The three laws of TDD
  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail, and; compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
F.I.R.S.T. rules
Single concept per test
The name of the test should reveal its intention
Concurrency
Prefer promises vs callbacks
Async/Await are even cleaner than Promises
Error Handling
Thrown errors are a good thing! They mean the runtime has successfully identified when something in your program has gone wrong and it's letting you know by stopping function
execution on the current stack, killing the process (in Node), and notifying you in the console with a stack trace.
Always use Error for throwing or rejecting
Don't ignore caught errors
Don't ignore rejected promises
Migrating from TSLint to ESLint
Code Organization
Use consistent capitalization
Organize imports
Use typescript aliases
Comments
The use of a comments is an indication of failure to express without them. Code should be the only source of truth.
Don’t comment bad code—rewrite it.
— Brian W. Kernighan and P. J. Plaugher
Prefer self explanatory code instead of comments
Don't leave commented out code in your codebase
Don't have journal comments
Avoid positional markers
TODO comments
About
A Reactjs coding style guide
linuxdevil.github.io/React-Style-Guide/
Topics
jsprinciplesreactreactjsstandardsstyle-guidestyleguidetypescript
Resources
Readme
Activity
Stars
7 stars
Watchers
1 watching
Forks
0 forks
Report repository
Contributors

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
Code Principles
Hi All ❤️
There are a few of these principles that will be universally accepted, but not all of them must be completely adhered to. These are merely guidelines,

but ones that have been formalized over a long period of time.
One more thing: even if you have years of experience with them, knowing them won't make you a better software developer right away.

Like wet clay being molded into its final form, every line of code begins as a first draft.

When we review it with our colleagues/friends, we finally chisel out the flaws. Don't be hard on yourself if your early drafts need work. Instead, abuse the code!
Let's code our wisdom like a melodic poetry ❤️
To keep in mind:
  • Use type annotations to explicitly declare the types of variables, function arguments, and return values. This makes it clear to other developers (and to the TypeScript compiler) what the expected types are, and can help prevent type errors.
  • Use interfaces to define the shape of complex types, such as objects with multiple properties or arrays with specific elements. This can make your code more self-documenting and easier to understand.
  • Use classes and encapsulation to organize your code into logical units and protect the internal state of your objects from being modified by external code.
  • Follow the SOLID principles of object-oriented design to create code that is easy to understand, maintain, and extend.
DRY (Don't Repeat Yourself)
 KISS (Keep it simple, stupid)
YAGNI (You ain't gonna need it)
Variables
Use meaningful variable names
Use pronounceable variable names
Use the same vocabulary for the same type of variable
Use searchable names
Use explanatory variables
Avoid Mental Mapping
Use default arguments instead of short circuiting or conditionals
Use enum to document the intent
Functions
Function callers and callees should be close
Function arguments (2 or fewer ideally)
Functions should do one thing
Function names should say what they do
Functions should only be one level of abstraction
Remove duplicate code
Set default objects with Object.assign or destructuring
Don't use flags as function parameters
Avoid Side Effects (part 1)
Avoid Side Effects (part 2)
Don't write to global functions
Favor functional programming over imperative programming
Encapsulate conditionals
Avoid negative conditionals
Avoid conditionals
Avoid type checking
Don't over-optimize
Remove dead code
Use iterators and generators
Objects and Data Structures
Use getters and setters
Make objects have private/protected members
Prefer immutability
type vs. interface
Classes
Classes should be small
High cohesion and low coupling
Prefer composition over inheritance
Use method chaining
SOLID
Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)
Testing
Testing is more important than shipping. If you have no tests or an inadequate amount, then every time you ship code you won't be sure that you didn't break anything.

Deciding on what constitutes an adequate amount is up to your team, but having 100% coverage (all statements and branches)

is how you achieve very high confidence and developer peace of mind. This means that in addition to having a great testing framework, you also need to use a good coverage tool.
There's no excuse to not write tests. There are plenty of good JS test frameworks with typings support for TypeScript, so find one that your team prefers. When you find one that works for your team, then aim to always write tests for every new feature/module you introduce. If your preferred method is Test Driven Development (TDD), that is great, but the main point is to just make sure you are reaching your coverage goals before launching any feature, or refactoring an existing one.
The three laws of TDD
  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail, and; compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
F.I.R.S.T. rules
Single concept per test
The name of the test should reveal its intention
Concurrency
Prefer promises vs callbacks
Async/Await are even cleaner than Promises
Error Handling
Thrown errors are a good thing! They mean the runtime has successfully identified when something in your program has gone wrong and it's letting you know by stopping function
execution on the current stack, killing the process (in Node), and notifying you in the console with a stack trace.
Always use Error for throwing or rejecting
Don't ignore caught errors
Don't ignore rejected promises
Migrating from TSLint to ESLint
Code Organization
Use consistent capitalization
Organize imports
Use typescript aliases
Comments
The use of a comments is an indication of failure to express without them. Code should be the only source of truth.
Don’t comment bad code—rewrite it.
— Brian W. Kernighan and P. J. Plaugher
Prefer self explanatory code instead of comments
Don't leave commented out code in your codebase
Don't have journal comments
Avoid positional markers
TODO comments
About
A Reactjs coding style guide
linuxdevil.github.io/React-Style-Guide/
Topics
jsprinciplesreactreactjsstandardsstyle-guidestyleguidetypescript
Resources
Readme
Activity
Stars
7 stars
Watchers
1 watching
Forks
0 forks
Report repository
Contributors

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
Code Principles
Hi All ❤️
There are a few of these principles that will be universally accepted, but not all of them must be completely adhered to. These are merely guidelines,

but ones that have been formalized over a long period of time.
One more thing: even if you have years of experience with them, knowing them won't make you a better software developer right away.

Like wet clay being molded into its final form, every line of code begins as a first draft.

When we review it with our colleagues/friends, we finally chisel out the flaws. Don't be hard on yourself if your early drafts need work. Instead, abuse the code!
Let's code our wisdom like a melodic poetry ❤️
To keep in mind:
  • Use type annotations to explicitly declare the types of variables, function arguments, and return values. This makes it clear to other developers (and to the TypeScript compiler) what the expected types are, and can help prevent type errors.
  • Use interfaces to define the shape of complex types, such as objects with multiple properties or arrays with specific elements. This can make your code more self-documenting and easier to understand.
  • Use classes and encapsulation to organize your code into logical units and protect the internal state of your objects from being modified by external code.
  • Follow the SOLID principles of object-oriented design to create code that is easy to understand, maintain, and extend.
DRY (Don't Repeat Yourself)
 KISS (Keep it simple, stupid)
YAGNI (You ain't gonna need it)
Variables
Use meaningful variable names
Use pronounceable variable names
Use the same vocabulary for the same type of variable
Use searchable names
Use explanatory variables
Avoid Mental Mapping
Use default arguments instead of short circuiting or conditionals
Use enum to document the intent
Functions
Function callers and callees should be close
Function arguments (2 or fewer ideally)
Functions should do one thing
Function names should say what they do
Functions should only be one level of abstraction
Remove duplicate code
Set default objects with Object.assign or destructuring
Don't use flags as function parameters
Avoid Side Effects (part 1)
Avoid Side Effects (part 2)
Don't write to global functions
Favor functional programming over imperative programming
Encapsulate conditionals
Avoid negative conditionals
Avoid conditionals
Avoid type checking
Don't over-optimize
Remove dead code
Use iterators and generators
Objects and Data Structures
Use getters and setters
Make objects have private/protected members
Prefer immutability
type vs. interface
Classes
Classes should be small
High cohesion and low coupling
Prefer composition over inheritance
Use method chaining
SOLID
Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)
Testing
Testing is more important than shipping. If you have no tests or an inadequate amount, then every time you ship code you won't be sure that you didn't break anything.

Deciding on what constitutes an adequate amount is up to your team, but having 100% coverage (all statements and branches)

is how you achieve very high confidence and developer peace of mind. This means that in addition to having a great testing framework, you also need to use a good coverage tool.
There's no excuse to not write tests. There are plenty of good JS test frameworks with typings support for TypeScript, so find one that your team prefers. When you find one that works for your team, then aim to always write tests for every new feature/module you introduce. If your preferred method is Test Driven Development (TDD), that is great, but the main point is to just make sure you are reaching your coverage goals before launching any feature, or refactoring an existing one.
The three laws of TDD
  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail, and; compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
F.I.R.S.T. rules
Single concept per test
The name of the test should reveal its intention
Concurrency
Prefer promises vs callbacks
Async/Await are even cleaner than Promises
Error Handling
Thrown errors are a good thing! They mean the runtime has successfully identified when something in your program has gone wrong and it's letting you know by stopping function
execution on the current stack, killing the process (in Node), and notifying you in the console with a stack trace.
Always use Error for throwing or rejecting
Don't ignore caught errors
Don't ignore rejected promises
Migrating from TSLint to ESLint
Code Organization
Use consistent capitalization
Organize imports
Use typescript aliases
Comments
The use of a comments is an indication of failure to express without them. Code should be the only source of truth.
Don’t comment bad code—rewrite it.
— Brian W. Kernighan and P. J. Plaugher
Prefer self explanatory code instead of comments
Don't leave commented out code in your codebase
Don't have journal comments
Avoid positional markers
TODO comments
About
A Reactjs coding style guide
linuxdevil.github.io/React-Style-Guide/
Topics
jsprinciplesreactreactjsstandardsstyle-guidestyleguidetypescript
Resources
Readme
Activity
Stars
7 stars
Watchers
1 watching
Forks
0 forks
Report repository
Contributors

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
BranchesTags
Repository files navigation
Code Principles
Hi All ❤️
There are a few of these principles that will be universally accepted, but not all of them must be completely adhered to. These are merely guidelines,

but ones that have been formalized over a long period of time.
One more thing: even if you have years of experience with them, knowing them won't make you a better software developer right away.

Like wet clay being molded into its final form, every line of code begins as a first draft.

When we review it with our colleagues/friends, we finally chisel out the flaws. Don't be hard on yourself if your early drafts need work. Instead, abuse the code!
Let's code our wisdom like a melodic poetry ❤️
To keep in mind:
  • Use type annotations to explicitly declare the types of variables, function arguments, and return values. This makes it clear to other developers (and to the TypeScript compiler) what the expected types are, and can help prevent type errors.
  • Use interfaces to define the shape of complex types, such as objects with multiple properties or arrays with specific elements. This can make your code more self-documenting and easier to understand.
  • Use classes and encapsulation to organize your code into logical units and protect the internal state of your objects from being modified by external code.
  • Follow the SOLID principles of object-oriented design to create code that is easy to understand, maintain, and extend.
DRY (Don't Repeat Yourself)
 KISS (Keep it simple, stupid)
YAGNI (You ain't gonna need it)
Variables
Use meaningful variable names
Use pronounceable variable names
Use the same vocabulary for the same type of variable
Use searchable names
Use explanatory variables
Avoid Mental Mapping
Use default arguments instead of short circuiting or conditionals
Use enum to document the intent
Functions
Function callers and callees should be close
Function arguments (2 or fewer ideally)
Functions should do one thing
Function names should say what they do
Functions should only be one level of abstraction
Remove duplicate code
Set default objects with Object.assign or destructuring
Don't use flags as function parameters
Avoid Side Effects (part 1)
Avoid Side Effects (part 2)
Don't write to global functions
Favor functional programming over imperative programming
Encapsulate conditionals
Avoid negative conditionals
Avoid conditionals
Avoid type checking
Don't over-optimize
Remove dead code
Use iterators and generators
Objects and Data Structures
Use getters and setters
Make objects have private/protected members
Prefer immutability
type vs. interface
Classes
Classes should be small
High cohesion and low coupling
Prefer composition over inheritance
Use method chaining
SOLID
Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)
Testing
Testing is more important than shipping. If you have no tests or an inadequate amount, then every time you ship code you won't be sure that you didn't break anything.

Deciding on what constitutes an adequate amount is up to your team, but having 100% coverage (all statements and branches)

is how you achieve very high confidence and developer peace of mind. This means that in addition to having a great testing framework, you also need to use a good coverage tool.
There's no excuse to not write tests. There are plenty of good JS test frameworks with typings support for TypeScript, so find one that your team prefers. When you find one that works for your team, then aim to always write tests for every new feature/module you introduce. If your preferred method is Test Driven Development (TDD), that is great, but the main point is to just make sure you are reaching your coverage goals before launching any feature, or refactoring an existing one.
The three laws of TDD
  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail, and; compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
F.I.R.S.T. rules
Single concept per test
The name of the test should reveal its intention
Concurrency
Prefer promises vs callbacks
Async/Await are even cleaner than Promises
Error Handling
Thrown errors are a good thing! They mean the runtime has successfully identified when something in your program has gone wrong and it's letting you know by stopping function
execution on the current stack, killing the process (in Node), and notifying you in the console with a stack trace.
Always use Error for throwing or rejecting
Don't ignore caught errors
Don't ignore rejected promises
Migrating from TSLint to ESLint
Code Organization
Use consistent capitalization
Organize imports
Use typescript aliases
Comments
The use of a comments is an indication of failure to express without them. Code should be the only source of truth.
Don’t comment bad code—rewrite it.
— Brian W. Kernighan and P. J. Plaugher
Prefer self explanatory code instead of comments
Don't leave commented out code in your codebase
Don't have journal comments
Avoid positional markers
TODO comments
About
A Reactjs coding style guide
linuxdevil.github.io/React-Style-Guide/
Topics
jsprinciplesreactreactjsstandardsstyle-guidestyleguidetypescript
Resources
Readme
Activity
Stars
7 stars
Watchers
1 watching
Forks
0 forks
Report repository
Contributors

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
Code Principles
Hi All ❤️
There are a few of these principles that will be universally accepted, but not all of them must be completely adhered to. These are merely guidelines,

but ones that have been formalized over a long period of time.
One more thing: even if you have years of experience with them, knowing them won't make you a better software developer right away.

Like wet clay being molded into its final form, every line of code begins as a first draft.

When we review it with our colleagues/friends, we finally chisel out the flaws. Don't be hard on yourself if your early drafts need work. Instead, abuse the code!
Let's code our wisdom like a melodic poetry ❤️
To keep in mind:
  • Use type annotations to explicitly declare the types of variables, function arguments, and return values. This makes it clear to other developers (and to the TypeScript compiler) what the expected types are, and can help prevent type errors.
  • Use interfaces to define the shape of complex types, such as objects with multiple properties or arrays with specific elements. This can make your code more self-documenting and easier to understand.
  • Use classes and encapsulation to organize your code into logical units and protect the internal state of your objects from being modified by external code.
  • Follow the SOLID principles of object-oriented design to create code that is easy to understand, maintain, and extend.
DRY (Don't Repeat Yourself)
 KISS (Keep it simple, stupid)
YAGNI (You ain't gonna need it)
Variables
Use meaningful variable names
Use pronounceable variable names
Use the same vocabulary for the same type of variable
Use searchable names
Use explanatory variables
Avoid Mental Mapping
Use default arguments instead of short circuiting or conditionals
Use enum to document the intent
Functions
Function callers and callees should be close
Function arguments (2 or fewer ideally)
Functions should do one thing
Function names should say what they do
Functions should only be one level of abstraction
Remove duplicate code
Set default objects with Object.assign or destructuring
Don't use flags as function parameters
Avoid Side Effects (part 1)
Avoid Side Effects (part 2)
Don't write to global functions
Favor functional programming over imperative programming
Encapsulate conditionals
Avoid negative conditionals
Avoid conditionals
Avoid type checking
Don't over-optimize
Remove dead code
Use iterators and generators
Objects and Data Structures
Use getters and setters
Make objects have private/protected members
Prefer immutability
type vs. interface
Classes
Classes should be small
High cohesion and low coupling
Prefer composition over inheritance
Use method chaining
SOLID
Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)
Testing
Testing is more important than shipping. If you have no tests or an inadequate amount, then every time you ship code you won't be sure that you didn't break anything.

Deciding on what constitutes an adequate amount is up to your team, but having 100% coverage (all statements and branches)

is how you achieve very high confidence and developer peace of mind. This means that in addition to having a great testing framework, you also need to use a good coverage tool.
There's no excuse to not write tests. There are plenty of good JS test frameworks with typings support for TypeScript, so find one that your team prefers. When you find one that works for your team, then aim to always write tests for every new feature/module you introduce. If your preferred method is Test Driven Development (TDD), that is great, but the main point is to just make sure you are reaching your coverage goals before launching any feature, or refactoring an existing one.
The three laws of TDD
  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail, and; compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
F.I.R.S.T. rules
Single concept per test
The name of the test should reveal its intention
Concurrency
Prefer promises vs callbacks
Async/Await are even cleaner than Promises
Error Handling
Thrown errors are a good thing! They mean the runtime has successfully identified when something in your program has gone wrong and it's letting you know by stopping function
execution on the current stack, killing the process (in Node), and notifying you in the console with a stack trace.
Always use Error for throwing or rejecting
Don't ignore caught errors
Don't ignore rejected promises
Migrating from TSLint to ESLint
Code Organization
Use consistent capitalization
Organize imports
Use typescript aliases
Comments
The use of a comments is an indication of failure to express without them. Code should be the only source of truth.
Don’t comment bad code—rewrite it.
— Brian W. Kernighan and P. J. Plaugher
Prefer self explanatory code instead of comments
Don't leave commented out code in your codebase
Don't have journal comments
Avoid positional markers
TODO comments
About
A Reactjs coding style guide
linuxdevil.github.io/React-Style-Guide/
Topics
jsprinciplesreactreactjsstandardsstyle-guidestyleguidetypescript
Resources
Readme
Activity
Stars
7 stars
Watchers
1 watching
Forks
0 forks
Report repository
Contributors

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
Code Principles
Hi All ❤️
There are a few of these principles that will be universally accepted, but not all of them must be completely adhered to. These are merely guidelines,

but ones that have been formalized over a long period of time.
One more thing: even if you have years of experience with them, knowing them won't make you a better software developer right away.

Like wet clay being molded into its final form, every line of code begins as a first draft.

When we review it with our colleagues/friends, we finally chisel out the flaws. Don't be hard on yourself if your early drafts need work. Instead, abuse the code!
Let's code our wisdom like a melodic poetry ❤️
To keep in mind:
  • Use type annotations to explicitly declare the types of variables, function arguments, and return values. This makes it clear to other developers (and to the TypeScript compiler) what the expected types are, and can help prevent type errors.
  • Use interfaces to define the shape of complex types, such as objects with multiple properties or arrays with specific elements. This can make your code more self-documenting and easier to understand.
  • Use classes and encapsulation to organize your code into logical units and protect the internal state of your objects from being modified by external code.
  • Follow the SOLID principles of object-oriented design to create code that is easy to understand, maintain, and extend.
DRY (Don't Repeat Yourself)
 KISS (Keep it simple, stupid)
YAGNI (You ain't gonna need it)
Variables
Use meaningful variable names
Use pronounceable variable names
Use the same vocabulary for the same type of variable
Use searchable names
Use explanatory variables
Avoid Mental Mapping
Use default arguments instead of short circuiting or conditionals
Use enum to document the intent
Functions
Function callers and callees should be close
Function arguments (2 or fewer ideally)
Functions should do one thing
Function names should say what they do
Functions should only be one level of abstraction
Remove duplicate code
Set default objects with Object.assign or destructuring
Don't use flags as function parameters
Avoid Side Effects (part 1)
Avoid Side Effects (part 2)
Don't write to global functions
Favor functional programming over imperative programming
Encapsulate conditionals
Avoid negative conditionals
Avoid conditionals
Avoid type checking
Don't over-optimize
Remove dead code
Use iterators and generators
Objects and Data Structures
Use getters and setters
Make objects have private/protected members
Prefer immutability
type vs. interface
Classes
Classes should be small
High cohesion and low coupling
Prefer composition over inheritance
Use method chaining
SOLID
Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)
Testing
Testing is more important than shipping. If you have no tests or an inadequate amount, then every time you ship code you won't be sure that you didn't break anything.

Deciding on what constitutes an adequate amount is up to your team, but having 100% coverage (all statements and branches)

is how you achieve very high confidence and developer peace of mind. This means that in addition to having a great testing framework, you also need to use a good coverage tool.
There's no excuse to not write tests. There are plenty of good JS test frameworks with typings support for TypeScript, so find one that your team prefers. When you find one that works for your team, then aim to always write tests for every new feature/module you introduce. If your preferred method is Test Driven Development (TDD), that is great, but the main point is to just make sure you are reaching your coverage goals before launching any feature, or refactoring an existing one.
The three laws of TDD
  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail, and; compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
F.I.R.S.T. rules
Single concept per test
The name of the test should reveal its intention
Concurrency
Prefer promises vs callbacks
Async/Await are even cleaner than Promises
Error Handling
Thrown errors are a good thing! They mean the runtime has successfully identified when something in your program has gone wrong and it's letting you know by stopping function
execution on the current stack, killing the process (in Node), and notifying you in the console with a stack trace.
Always use Error for throwing or rejecting
Don't ignore caught errors
Don't ignore rejected promises
Migrating from TSLint to ESLint
Code Organization
Use consistent capitalization
Organize imports
Use typescript aliases
Comments
The use of a comments is an indication of failure to express without them. Code should be the only source of truth.
Don’t comment bad code—rewrite it.
— Brian W. Kernighan and P. J. Plaugher
Prefer self explanatory code instead of comments
Don't leave commented out code in your codebase
Don't have journal comments
Avoid positional markers
TODO comments
About
A Reactjs coding style guide
linuxdevil.github.io/React-Style-Guide/
Topics
jsprinciplesreactreactjsstandardsstyle-guidestyleguidetypescript
Resources
Readme
Activity
Stars
7 stars
Watchers
1 watching
Forks
0 forks
Report repository
Contributors

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
BranchesTags
Repository files navigation
Code Principles
Hi All ❤️
There are a few of these principles that will be universally accepted, but not all of them must be completely adhered to. These are merely guidelines,

but ones that have been formalized over a long period of time.
One more thing: even if you have years of experience with them, knowing them won't make you a better software developer right away.

Like wet clay being molded into its final form, every line of code begins as a first draft.

When we review it with our colleagues/friends, we finally chisel out the flaws. Don't be hard on yourself if your early drafts need work. Instead, abuse the code!
Let's code our wisdom like a melodic poetry ❤️
To keep in mind:
  • Use type annotations to explicitly declare the types of variables, function arguments, and return values. This makes it clear to other developers (and to the TypeScript compiler) what the expected types are, and can help prevent type errors.
  • Use interfaces to define the shape of complex types, such as objects with multiple properties or arrays with specific elements. This can make your code more self-documenting and easier to understand.
  • Use classes and encapsulation to organize your code into logical units and protect the internal state of your objects from being modified by external code.
  • Follow the SOLID principles of object-oriented design to create code that is easy to understand, maintain, and extend.
DRY (Don't Repeat Yourself)
 KISS (Keep it simple, stupid)
YAGNI (You ain't gonna need it)
Variables
Use meaningful variable names
Use pronounceable variable names
Use the same vocabulary for the same type of variable
Use searchable names
Use explanatory variables
Avoid Mental Mapping
Use default arguments instead of short circuiting or conditionals
Use enum to document the intent
Functions
Function callers and callees should be close
Function arguments (2 or fewer ideally)
Functions should do one thing
Function names should say what they do
Functions should only be one level of abstraction
Remove duplicate code
Set default objects with Object.assign or destructuring
Don't use flags as function parameters
Avoid Side Effects (part 1)
Avoid Side Effects (part 2)
Don't write to global functions
Favor functional programming over imperative programming
Encapsulate conditionals
Avoid negative conditionals
Avoid conditionals
Avoid type checking
Don't over-optimize
Remove dead code
Use iterators and generators
Objects and Data Structures
Use getters and setters
Make objects have private/protected members
Prefer immutability
type vs. interface
Classes
Classes should be small
High cohesion and low coupling
Prefer composition over inheritance
Use method chaining
SOLID
Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)
Testing
Testing is more important than shipping. If you have no tests or an inadequate amount, then every time you ship code you won't be sure that you didn't break anything.

Deciding on what constitutes an adequate amount is up to your team, but having 100% coverage (all statements and branches)

is how you achieve very high confidence and developer peace of mind. This means that in addition to having a great testing framework, you also need to use a good coverage tool.
There's no excuse to not write tests. There are plenty of good JS test frameworks with typings support for TypeScript, so find one that your team prefers. When you find one that works for your team, then aim to always write tests for every new feature/module you introduce. If your preferred method is Test Driven Development (TDD), that is great, but the main point is to just make sure you are reaching your coverage goals before launching any feature, or refactoring an existing one.
The three laws of TDD
  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail, and; compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
F.I.R.S.T. rules
Single concept per test
The name of the test should reveal its intention
Concurrency
Prefer promises vs callbacks
Async/Await are even cleaner than Promises
Error Handling
Thrown errors are a good thing! They mean the runtime has successfully identified when something in your program has gone wrong and it's letting you know by stopping function
execution on the current stack, killing the process (in Node), and notifying you in the console with a stack trace.
Always use Error for throwing or rejecting
Don't ignore caught errors
Don't ignore rejected promises
Migrating from TSLint to ESLint
Code Organization
Use consistent capitalization
Organize imports
Use typescript aliases
Comments
The use of a comments is an indication of failure to express without them. Code should be the only source of truth.
Don’t comment bad code—rewrite it.
— Brian W. Kernighan and P. J. Plaugher
Prefer self explanatory code instead of comments
Don't leave commented out code in your codebase
Don't have journal comments
Avoid positional markers
TODO comments
About
A Reactjs coding style guide
linuxdevil.github.io/React-Style-Guide/
Topics
jsprinciplesreactreactjsstandardsstyle-guidestyleguidetypescript
Resources
Readme
Activity
Stars
7 stars
Watchers
1 watching
Forks
0 forks
Report repository
Contributors