This a list of state-of-the-art shitcode principles your project should follow.
Get Your Badge
If your repository follows the state-of-the-art shitcode principles you may use the following "state-of-the-art shitcode" badge:
[![State-of-the-art Shitcode](https://img.shields.io/static/v1?label=State-of-the-art&message=Shitcode&color=7B5804)](https://github.com/trekhleb/state-of-the-art-shitcode)
The Principles
๐ฉ Name variables in a way as if your code was already obfuscated
Less keystrokes, more time for you.
Good ๐๐ป
let a = 42;
Bad ๐๐ป
let age = 42;
๐ฉ Mix variable/functions naming style
Celebrate the difference.
Good ๐๐ป
let wWidth = 640;
let w_height = 480;
Bad ๐๐ป
let windowWidth = 640;
let windowHeight = 480;
๐ฉ Never write comments
No one is going to read your code anyway.
Good ๐๐ป
const cdr = 700;
Bad ๐๐ป
// Callback function debounce rate in milliseconds.
const callbackDebounceRate = 700;
๐ฉ Always write comments in your native language
If you violated the "No comments" principle then at least try to write comments in a language that is different from the language you use to write the code. If your native language is English you may violate this principle.
Good ๐๐ป
// ะะฐะบัะธะฒะฐัะผะพ ะผะพะดะฐะปัะฝะต ะฒัะบะพะฝะตัะบะพ ะฟัะธ ะฒะธะฝะธะบะฝะตะฝะฝั ะฟะพะผะธะปะบะธ.
toggleModal(false);
Bad ๐๐ป
// Hide modal window on error.
toggleModal(false);
๐ฉ Try to mix formatting style as much as possible
Celebrate the difference.
Good ๐๐ป
let i = ['tomato', 'onion', 'mushrooms'];
let d = [ "ketchup", "mayonnaise" ];
Bad ๐๐ป
let ingredients = ['tomato', 'onion', 'mushrooms'];
let dressings = ['ketchup', 'mayonnaise'];
๐ฉ Put as much code as possible into one line
Good ๐๐ป
document.location.search.replace(/(^\?)/,'').split('&').reduce(function(o,n){n=n.split('=');o[n[0]]=n[1];return o},{})
Bad ๐๐ป
document.location.search
.replace(/(^\?)/, '')
.split('&')
.reduce((searchParams, keyValuePair) => {
keyValuePair = keyValuePair.split('=');
searchParams[keyValuePair[0]] = keyValuePair[1];
return searchParams;
},
{}
)
๐ฉ Fail silently
Whenever you catch an error it is not necessary for anyone to know about it. No logs, no error modals, chill.
Good ๐๐ป
try {
// Something unpredictable.
} catch (error) {
// tss... ๐คซ
}
Bad ๐๐ป
try {
// Something unpredictable.
} catch (error) {
setErrorMessage(error.message);
// and/or
logError(error);
}
๐ฉ Do not lock your dependencies
Update your dependencies on each new installation in uncontrolled way. Why stick to the past, let's use the cutting edge libraries versions.
Good ๐๐ป
$ ls -la
package.json
Bad ๐๐ป
$ ls -la
package.json
package-lock.json
๐ฉ Triangle principle
Be like a bird - nest, nest, nest.
Good ๐๐ป
function someFunction() {
if (condition1) {
if (condition2) {
asyncFunction(params, (result) => {
if (result) {
for (;;) {
if (condition3) {
}
}
}
})
}
}
}
Bad ๐๐ป
function someFunction() {
if (!condition1 || !condition2) {
return;
}
const result = await asyncFunction(params);
if (!result) {
return;
}
for (;;) {
if (condition3) {
}
}
}
๐ฉ Avoid covering your code with tests
This is a duplicate and unnecessary amount of work.
Top comments (5)
Thanks, Oleksii, for the great coverage of how a developer should write good code!
From my perspective, I would add the following:
Variables naming
The shorter, the better:
instead of
You should decrease your variables/functions names.
Comments
Write comments in your native language - totally agree!
In case you need to leave a comment about fixing something in the future, please use it like this:
Not like this:
One-line code
You should write a one-line code because it can save a ton of memory! Just imagine how much performance gain you reach once you rewrite your app into one-liners!
Errors
Just don't catch them, I agree with Oleksii. You will see errors if your app fails anyway, so why do you need to write additional code to catch them?
Callbacks vs. straightforward code
Use callbacks. Especially, if you have more than 5 of them.
Bonuses:
this
manipulatingDon't create too many variables, just use "this" context!
Examples:
Functions return signature
Write functions that can return multiple types and unexpected results like this:
Code linting
Just don't use tools for code linting. They only take additional place in your "package.json".
Write code as you want, especially if there is more than one developer in a team.
Unnecessary code
Don't delete the code your app doesn't use. At most, comment it.
Logic fragmentation
Don't divide a program logic into readable pieces. What if your IDE's search brokes and you will not be able to find the necessary file or function?
service.js
? It's OK.Very good points! I've updated the main list ๐๐ป
Fun post but
๐ฉ Never write comments
I would say that changing the variable name was enough, I think that the comment is redundant :D, if the fact that is in ms is not obvious I would put it in the variable name. For the example I would put something in the lines of
This is a very good point about the comments. I've updated the main list. Thanks!
I think we need an eslint plugin for that also!