state-of-the-art-shitcode
💩State-of-the-art shitcode principles your project should follow to call it a proper shitcode
Top Related Projects
👩🏿💻👨🏾💻👩🏼💻👨🏽💻👩🏻💻 Awesome Developers, Streaming
Interactive roadmaps, guides and other educational content to help developers grow in their careers.
:link: Some useful websites for programmers.
Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards.
:books: Freely available programming books
😎 Awesome lists about all kinds of interesting topics
Quick Overview
The "State of the Art Shitcode" repository is a humorous and educational project that showcases examples of poorly written code. It aims to demonstrate common anti-patterns and bad practices in software development, serving as a tongue-in-cheek guide on how not to write code. The project is meant to be both entertaining and instructive for developers of all levels.
Pros
- Provides clear examples of what not to do in coding, helping developers avoid common pitfalls
- Uses humor to make learning about code quality more engaging and memorable
- Covers a wide range of programming languages and concepts
- Encourages community contributions and discussions about best practices
Cons
- May be misinterpreted by beginners who might not understand the satirical nature of the content
- Some examples might be too exaggerated or unrealistic
- Could potentially reinforce negative stereotypes about certain programming languages or practices
- Lacks detailed explanations or solutions for each anti-pattern presented
Code Examples
- Example of unnecessary complexity:
def is_odd(num):
return bool(num & 1 == 1 if num > 0 else num < 0 and num & 1 == 1)
This code unnecessarily complicates a simple odd number check.
- Example of poor naming conventions:
function doStuff(a, b, c) {
let x = a + b;
let y = x * c;
return y - a;
}
This function uses vague names that don't convey the purpose of the variables or the function itself.
- Example of redundant code:
if (condition == true) {
return true;
} else {
return false;
}
This code block can be simplified to just return condition;
.
Getting Started
As this is not a code library but rather a collection of examples, there's no specific installation or setup required. To explore the project:
- Visit the GitHub repository: https://github.com/trekhleb/state-of-the-art-shitcode
- Browse through the examples in different programming languages
- Read the discussions and comments to understand why each example is considered poor practice
- Consider contributing your own examples or improvements to existing ones
Remember, the goal is to learn from these examples and improve your coding practices, not to replicate them in real projects!
Competitor Comparisons
👩🏿💻👨🏾💻👩🏼💻👨🏽💻👩🏻💻 Awesome Developers, Streaming
Pros of awesome-developer-streams
- Provides a curated list of valuable resources for developers interested in live coding streams
- Regularly updated with new content and streams
- Well-organized by programming languages and topics
Cons of awesome-developer-streams
- Limited to streaming content, not covering other learning resources
- May include inactive or outdated streams
Code comparison
Not applicable, as both repositories don't contain significant code samples. state-of-the-art-shitcode focuses on examples of bad coding practices, while awesome-developer-streams is a curated list of resources.
Summary
state-of-the-art-shitcode is a humorous repository showcasing examples of poor coding practices, aimed at educating developers on what to avoid. On the other hand, awesome-developer-streams is a curated list of live coding streams, providing valuable resources for developers to learn from experienced programmers in real-time.
While state-of-the-art-shitcode offers a unique approach to learning through negative examples, awesome-developer-streams provides a more traditional method of learning through observation and interaction with skilled developers.
Both repositories serve different purposes in the developer community, with state-of-the-art-shitcode focusing on code quality and best practices, and awesome-developer-streams emphasizing continuous learning and community engagement through live streaming platforms.
Interactive roadmaps, guides and other educational content to help developers grow in their careers.
Pros of developer-roadmap
- Provides comprehensive learning paths for various tech roles
- Regularly updated with new technologies and industry trends
- Offers interactive roadmaps with clickable resources
Cons of developer-roadmap
- May overwhelm beginners with the sheer amount of information
- Focuses more on breadth than depth in specific technologies
- Lacks humor and entertainment value found in state-of-the-art-shitcode
Code comparison
While state-of-the-art-shitcode provides examples of poor coding practices:
function checkAge(age) {
if (age < 18) {
return false;
} else {
return true;
}
}
developer-roadmap doesn't include code snippets but offers guidance on best practices:
## Frontend Development
- Learn HTML
- Basic syntax
- Semantic HTML
- Learn CSS
- Layouts (Flexbox, Grid)
- Responsive design
developer-roadmap focuses on structured learning paths, while state-of-the-art-shitcode humorously highlights common coding mistakes. The former is a serious educational resource, while the latter serves as an entertaining cautionary tale for developers.
:link: Some useful websites for programmers.
Pros of Best-websites-a-programmer-should-visit
- Provides a curated list of valuable resources for programmers
- Covers a wide range of topics, from coding practice to career development
- Regularly updated with new and relevant websites
Cons of Best-websites-a-programmer-should-visit
- Lacks humor and entertainment value
- Doesn't provide direct coding examples or guidelines
- May overwhelm users with the sheer number of resources
Code Comparison
While Best-websites-a-programmer-should-visit doesn't contain code examples, state-of-the-art-shitcode provides humorous examples of bad coding practices. Here's a sample from state-of-the-art-shitcode:
function isOdd(number) {
return !!(number & 1);
}
function isEven(number) {
return !isOdd(number);
}
This example demonstrates unnecessarily complex ways to check for odd and even numbers, which is the opposite of what Best-websites-a-programmer-should-visit aims to promote through its curated resources.
In summary, Best-websites-a-programmer-should-visit is a serious, comprehensive resource for programmers seeking to improve their skills and knowledge. On the other hand, state-of-the-art-shitcode takes a humorous approach to highlight bad coding practices, serving as a lighthearted reminder of what to avoid in programming.
Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards.
Pros of system-design-primer
- Comprehensive resource for learning system design concepts
- Well-organized content with clear explanations and diagrams
- Actively maintained with regular updates and contributions
Cons of system-design-primer
- More serious and technical in nature, lacking humor
- Requires significant time investment to fully grasp the content
Code comparison
While state-of-the-art-shitcode focuses on humorous examples of bad coding practices, system-design-primer provides practical code snippets for system design concepts. Here's a brief comparison:
state-of-the-art-shitcode:
def is_odd(n):
return n > 0 and n % 2 == 1 or n < 0 and n % 2 == -1
system-design-primer:
def get_user(user_id):
user = cache.get(user_id)
if user is None:
user = db.query('SELECT * FROM users WHERE id = {}'.format(user_id))
cache.set(user_id, user)
return user
The state-of-the-art-shitcode example demonstrates an overly complex way to check for odd numbers, while the system-design-primer example shows a practical implementation of caching in a database query.
:books: Freely available programming books
Pros of free-programming-books
- Extensive collection of free educational resources for programmers
- Well-organized and categorized by programming languages and topics
- Regularly updated with community contributions
Cons of free-programming-books
- Lacks practical coding examples or exercises
- May not provide guidance on which resources are best for specific skill levels
Code comparison
Not applicable, as neither repository contains significant code samples. free-programming-books is primarily a curated list of resources, while state-of-the-art-shitcode focuses on humorous anti-patterns and bad coding practices.
Additional notes
state-of-the-art-shitcode:
- Humorous approach to teaching good coding practices through bad examples
- Provides concrete examples of what not to do in code
- May be more engaging for some learners due to its satirical nature
free-programming-books:
- More comprehensive and serious approach to programming education
- Covers a wider range of topics and languages
- Suitable for self-directed learning across various programming disciplines
Both repositories serve different purposes in the programming community. state-of-the-art-shitcode offers a unique, entertaining perspective on code quality, while free-programming-books provides a vast collection of learning resources for programmers at all levels.
😎 Awesome lists about all kinds of interesting topics
Pros of awesome
- Comprehensive collection of curated lists covering various topics
- Well-organized and easy to navigate
- Actively maintained with regular updates and contributions
Cons of awesome
- Can be overwhelming due to the sheer volume of information
- Some lists may contain outdated or less relevant resources
- Lacks specific focus on coding practices or techniques
Code comparison
Not applicable, as both repositories don't contain significant code samples. awesome is primarily a collection of links and resources, while state-of-the-art-shitcode focuses on describing anti-patterns and bad coding practices.
Summary
awesome is a vast collection of curated lists covering a wide range of topics in software development and technology. It serves as a valuable resource for developers seeking high-quality tools, libraries, and learning materials. On the other hand, state-of-the-art-shitcode is a humorous guide to writing terrible code, highlighting common mistakes and anti-patterns to avoid.
While awesome provides a wealth of information, it may be overwhelming for some users due to its extensive content. state-of-the-art-shitcode, although smaller in scope, offers a focused and entertaining approach to learning about code quality through negative examples.
Both repositories serve different purposes and can be valuable for developers, depending on their needs and learning preferences.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
State-of-the-Art Shitcode Principles
This a list of state-of-the-art shitcode principles your project should follow to call it a proper shitcode.
Read this in other languages: ç®ä½ä¸æ, íêµì´
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:
Markdown source-code for the 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
Fewer 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 ðð»
More often comments should contain some 'why' and not some 'what'. If the 'what' is not clear in the code, the code is probably too messy.
// The number of 700ms has been calculated empirically based on UX A/B test results.
// @see: <link to experiment or to related JIRA task or to something that explains number 700 in details>
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);
}
ð© Use global variables extensively
Globalization principle.
Good ðð»
let x = 5;
function square() {
x = x ** 2;
}
square(); // Now x is 25.
Bad ðð»
let x = 5;
function square(num) {
return num ** 2;
}
x = square(x); // Now x is 25.
ð© Create variables that you're not going to use.
Just in case.
Good ðð»
function sum(a, b, c) {
const timeout = 1300;
const result = a + b;
return a + b;
}
Bad ðð»
function sum(a, b) {
return a + b;
}
ð© Don't specify types and/or don't do type checks if language allows you to do so.
Good ðð»
function sum(a, b) {
return a + b;
}
// Having untyped fun here.
const guessWhat = sum([], {}); // -> "[object Object]"
const guessWhatAgain = sum({}, []); // -> 0
Bad ðð»
function sum(a: number, b: number): ?number {
// Covering the case when we don't do transpilation and/or Flow type checks in JS.
if (typeof a !== 'number' && typeof b !== 'number') {
return undefined;
}
return a + b;
}
// This one should fail during the transpilation/compilation.
const guessWhat = sum([], {}); // -> undefined
ð© You need to have an unreachable piece of code
This is your "Plan B".
Good ðð»
function square(num) {
if (typeof num === 'undefined') {
return undefined;
}
else {
return num ** 2;
}
return null; // This is my "Plan B".
}
Bad ðð»
function square(num) {
if (typeof num === 'undefined') {
return undefined;
}
return num ** 2;
}
ð© 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 ðð»
async function someFunction() {
if (!condition1 || !condition2) {
return;
}
const result = await asyncFunction(params);
if (!result) {
return;
}
for (;;) {
if (condition3) {
}
}
}
ð© Mess with indentations
Avoid indentations since they make complex code take up more space in the editor. If you're not feeling like avoiding them then just mess with them.
Good ðð»
const fruits = ['apple',
'orange', 'grape', 'pineapple'];
const toppings = ['syrup', 'cream',
'jam',
'chocolate'];
const desserts = [];
fruits.forEach(fruit => {
toppings.forEach(topping => {
desserts.push([
fruit,topping]);
});})
Bad ðð»
const fruits = ['apple', 'orange', 'grape', 'pineapple'];
const toppings = ['syrup', 'cream', 'jam', 'chocolate'];
const desserts = [];
fruits.forEach(fruit => {
toppings.forEach(topping => {
desserts.push([fruit, topping]);
});
})
ð© 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
ð© Always name your boolean value a flag
Leave the space for your colleagues to think what the boolean value means.
Good ðð»
let flag = true;
Bad ðð»
let isDone = false;
let isEmpty = false;
ð© Long-read functions are better than short ones.
Don't divide a program logic into readable pieces. What if your IDE's search breaks and you will not be able to find the necessary file or function?
- 10000 lines of code in one file is OK.
- 1000 lines of a function body is OK.
- Dealing with many services (3rd party and internal, also, there are some helpers, database hand-written ORM and jQuery slider) in one
service.js
? It's OK.
ð© Avoid covering your code with tests
This is a duplicate and unnecessary amount of work.
ð© As hard as you can try to avoid code linters
Write code as you want, especially if there is more than one developer in a team. This is a "freedom" principle.
ð© Start your project without a README file.
And keep it that way for the time being.
ð© You need to have unnecessary code
Don't delete the code your app doesn't use. At most, comment it.
Top Related Projects
👩🏿💻👨🏾💻👩🏼💻👨🏽💻👩🏻💻 Awesome Developers, Streaming
Interactive roadmaps, guides and other educational content to help developers grow in their careers.
:link: Some useful websites for programmers.
Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards.
:books: Freely available programming books
😎 Awesome lists about all kinds of interesting topics
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot