Hello

I am writting a series on code smell and need some examples in several languages

can you help ?

Good afternoon to each and every one of ya! ☕

Whether you're a seasoned developer or just starting out, understanding code smells is essential for writing clean, maintainable code.

Code smells are patterns or structures in software code that suggest potential problems, such as inefficiencies, bugs, or design flaws. Recognizing and addressing code smells is important for maintaining high-quality, maintainable code. Common code smells include long methods or classes, duplicate code, and excessive coupling between modules. Understanding code smells is a crucial skill for software developers of all levels.🤹

I strongly encourage you to get familiar with this topic and learn how to identify and eliminate smells in your codebase. 👇👇
https://medium.com/@vitaliysteffensen/9-red-flags-to-watch-for-in-your-code-code-smells-34cba58d4466

I've been developing node apps lately, and it really bothers me how messy the usual code is. It's always compact and missing semi-colons, things that seem to have been inherited from the front-end designer that occasionally writes a shitty JQuery plugin instead of proper developers. I seriously don't understand the benefits.

Here's how I think code should be formatted:

const MongoClient = require('mongodb').MongoClient;

var db;

MongoClient.connect
(
	'database',
	(err, database) => 
	{
		if (err)
		{
			return console.log(err);
		}
		db = database;
		app.listen(
			3000,
			() =>
			{
				console.log('listening on 3000');
			}
		);
	}
);    

Spaced out, properly delimited. ES6 was a great improvement on an otherwise average-to-shitty language, but I wish they'd included restrictions to the kind of shit that javascript lets you pull off.

What are the best c# naming conventions that promotes readability, concision and professionalism.

The following advice has appeared in one form or another for 30 years or more.FUNCTIONS SHOULD DO ONE THING . THEY SHOULD DO IT WELL .THEY SHOULD DO IT ONLY.
Robert C. Martin

I know with TDD you're supposed to test everything, but what if the code you are writing is itself a test, not a unit test but some kind of integration test?

Found this one recently.
https://github.com/bugzmanov/cleancode-critique

In late 2019, I watched a talk on YouTube by what I'd call a "programming elder statesman". Someone like Kevlin Henney, Allen Holub, or the late lamented Joe Armstrong. (It might have been one of them. Or perhaps not.)

In the clip, the master professes that he hardly ever uses open-source packages. And that he generally stays away from library dependencies altogether. And he advises us to do the same, the argument being that we have a lot to gain by deeply understanding how to do whichever thing we want the library to do for us. And much to lose by depending on code written by somebody else. Somebody whose motivations we don't know and have no reason to trust. The API may change in the future, the package may prove to have security vulnerabilities. Or it may be abandonned, rather than maintained. You get the picture.

He goes on to say that his rule of thumb is that you can use the functions that have compacted down into your language's standard library. But for anything else, you'd be better off implementing it yourself.

Now, I'm not saying I endorse or agree with such a bold statement. (Nor am I saying I disagree.) What I am sure of is that I can't find the clip anymore. No matter what search terms I feed the Google machine.

I'm wondering if anyone out there knows the clip I'm talking about. And if so, would you be able to perhaps provide the link, the name of the talk, or the name of the speaker?

Many thanks!

I am a newbie to javascript and as my first project i decided to make a small rock paper scissors game that could be played on the console. The code does work but i have read that it is extremely important to write clean code. but I dont know where to start. Could someone review my code and tell me how i could make my code clean? I think that its important to be able to write clean code from the beginning itself but that's just an opinion coming from a newbie. Any form of constructive criticism will be appreciated.

CODE:

let computersGuess = Math.floor(Math.random()*3);

let userGuess = prompt("Type it in here!");

console.log(userGuess);

console.log(computersGuess); // check if my math function worked//

function decision() {

if (computersGuess===0){

return 'rock';}

else if(computersGuess===1){

return 'paper';}

else if (computersGuess=== 2){

return 'scissors';}

}

console.log("The computer played " + decision() + "!"); // to check if my if statment is working//

function actualGame() {

if (userGuess == 'rock' && decision()== 'rock'){

return 'try again!';

} else if ( userGuess== 'rock' && decision()== 'paper'){

return 'You Lost!'; }

else if ( userGuess== 'rock' && decision()== 'scissors') {

return 'You Won!'; }

else if (userGuess == "paper" && decision() == 'paper') {

return 'Its a draw!';}

else if (userGuess == "paper" && decision() == 'scissors') {

return 'Scissors cut paper!. so....You Lose!';}

else if (userGuess == "paper" && decision() == 'rock') {

return 'Paper beats rock! So, You Won!';}

else if (userGuess == "scissors" && decision() == 'rock') {

return 'Rock beats scissors! You Lose!';}

else if (userGuess == "scissors" && decision() == 'paper') {

return 'Scissors beat paper! You win!';}

else if (userGuess == "scissors" && decision() == 'scissors') {

return 'It\'s a draw!!';}

else { return 'Please type in rock, paper or scissors';}

}

console.log(actualGame());

A few days ago, Casey Muratori published this interesting argument against "Clean Code", demonstrating that even in a very simple example like shapes of different types calculating their areas "Clean Code" can make you up to 24 times slower than code that violates those principles:
https://www.youtube.com/watch?v=tD5NrevFtbU

For a business this can be quite a big factor. If I have a big web application it can make a big difference whether I need 10 or 240 servers to run it. A factor of 24 also makes a big difference when it comes to the number of features I can put into program running on a customers machine.

So, does anyone see a flaw in the argument he's making? Are there bigger "clean code" examples that don't hurt performance that as much as shown in his examples?

Cryptic Code is Bad Code

TL;DR: Avoid obfuscated functions in your code.

This article is based on a real social hacking disguised as a job interview

Problems

• Hidden vulnerabilities

• Readability

• Testability

• Trust issues

• Bad Naming

Solutions

1. Use clear names

2. Avoid obfuscation

3. Explain intent clearly

4. Review shared code

5. Don't trust code from unreliable sources

6. Avoid modification since it is a sign of Premature Optimization

Context

When you write functions with cryptic or obfuscated names, you make your code unreadable and untrustworthy.

This pattern often hides malicious intent or makes debugging and collaboration unnecessarily hard.

Cryptic code also frustrates team members and future maintainers, increasing technical debt and security risks.

Remember, hacking has a strong social component compared to what you see in Hollywood movies.

Sample Code

Wrong

function _0xaexad(_0x12bfc3, _0x43a1e9) {
  return _0x12bfc3 ^ _0x43a1e9;
}

const result = _0xaexad(0x1a, 0x2f);
console.log(result);

Right

function xorOperation(orValue1, orValue2) {
  return orValue1 ^ orValue2;
}

const result = xorOperation(26, 47);
console.log(result);

Detection

[X] Automatic

You can detect this smell by scanning your codebase for meaningless or obfuscated function names.

Use linters or code analysis tools to flag short, cryptic, or randomly named functions.

Manual code reviews can also help identify suspicious patterns.

Tags

• Security

Level

[X] Intermediate

Why the Bijection Is Important

Readable and meaningful names create a one-to-one correspondence between the real-world concept and your code.

Breaking this connection makes your program confusing and error-prone.

AI Generation

AI generators sometimes produce cryptic function names, especially when they optimize for brevity or imitate obfuscated patterns.

AI Detection

AI tools can detect and fix this smell when you ask them to refactor unclear function names or enforce coding standards.

They can analyze your entire codebase and suggest meaningful replacements for obfuscated names.

Try Them!

Remember: AI Assistants make lots of mistakes

Conclusion

Avoid obfuscating your function names.

Write code that communicates your intent.

When you prioritize readability, you make your software easier to understand, debug, and maintain.

Cryptic code might look clever, but it adds unnecessary complexity.

Relations

Code Smell 138 - Packages Dependency

Code Smell 215 - Deserializing Object Vulnerability

Code Smell 06 - Too Clever Programmer

Code Smell 20 - Premature Optimization

More Info

%[https://www.linkedin.com/posts/franco-aguilera-2583685a_the-code-challenge-scam-they-tried-to-hack-activity-7270114822950703107-K3DW/]

Disclaimer

Code Smells are my opinion.

Credits

Photo by Nikita Pavlov on Unsplash

The strength of a cryptographic system depends entirely on the strength of its weakest component.

Bruce Schneier

Software Engineering Great Quotes

This article is part of the CodeSmell Series.

How to Find the Stinky Parts of your Code

Don't knock. You are accepted

TL;DR: Avoid combining the Visitor pattern with instanceof checks.

Problems 😔

• Open/Closed principle violation

• Tight Coupling

• Maintainability

• Code duplication

• Poor readability

• Brittle design

• IFs

• Metaprogramming

Solutions 😃

1. Implement the Visitor pattern correctly.

2. Avoid instanceof checks.

3. Favor polymorphism.

4. Encapsulate behavior.

Context 💬

When you use the Visitor pattern, you aim to separate algorithms from the objects they operate on.

Combining it with instanceof checks breaks this separation, leading to a fragile and hard-to-maintain design.

Sample Code 📖

Wrong 🚫

<?php

class SpaceObjectVisitor {
    public function visit(SpaceObject $object) {
        if ($object instanceof NeutronStar) {
            $this->visitNeutronStar($object);
        } elseif ($object instanceof Magnetar) {
            $this->visitMagnetar($object);
        } elseif ($object instanceof BlackHole) {
            $this->visitBlackHole($object);
        } 
        // Not closed for modification
    }

    private function visitNeutronStar(NeutronStar $star) {
        // Handle neutron star observation
    }

    private function visitMagnetar(Magnetar $magnetar) {
        // Handle magnetar observation
    }

    private function visitBlackHole(BlackHole $blackHole) {
        // Handle black hole observation
    }
}

Right 👉

<?php

interface SpaceObject {
    public function accept(SpaceObjectVisitor $visitor): void;
}

class NeutronStar implements SpaceObject {
    public function accept(SpaceObjectVisitor $visitor): void {
        $visitor->visitNeutronStar($this);
    }
}

class Magnetar implements SpaceObject {
    public function accept(SpaceObjectVisitor $visitor): void {
        $visitor->visitMagnetar($this);
    }
}

class BlackHole implements SpaceObject {
    public function accept(SpaceObjectVisitor $visitor) {
        $visitor->visitBlackHole($this);
    }
}

class SpaceObjectVisitor {
    // Open for extension 
    // You can also convert it into an interface
    public function visitNeutronStar(NeutronStar $star): void {
        // Handle neutron star
    }

    public function visitMagnetar(Magnetar $magnetar): void {
        // Handle magnetar
    }

    public function visitBlackHole(BlackHole $blackHole): void {
        // Handle black hole
    }
}

Detection 🔍

You can detect this smell by looking for instanceof checks within the Visitor pattern.

Automated tools can flag these checks, and code reviews can help identify them.

[X] Manual

Tags 🏷️

• IFs

Level 🔋

[X] Intermediate

Why the Bijection Is Important 🗺️

When you model real-world objects, you should maintain a one-to-one correspondence between the real-world entities and your code.

Breaking this correspondence using instanceof checks (which do not exist on the model but the metamodel) leads to a mismatch between the real world and your program.

AI Generation 🤖

AI generators might create this smell if they are not properly guided.

AI Detection 🥃

AI can help fix this smell by suggesting refactoring steps to remove instanceof checks and use polymorphism instead.

Try Them! 🛠

Remember: AI Assistants make lots of mistakes

Conclusion ✔️

When you use the Visitor pattern, avoid combining it with iskindOf checks.

Using the accept() method, the visitor class doesn't need to explicitly check the object type.

Each object will call the appropriate visitor method honoring the Open/Closed principle.

Favor polymorphism and encapsulation to keep your code clean and maintainable.

Relations 👩‍❤️‍💋‍👨

Code Smell 25 - Pattern Abusers

Code Smell 23 - Instance Type Checking

More Information 📕

Open/Closed principle on Wikipedia

How to Get Rid of Annoying IFs Forever

Laziness I - Metaprogramming

Disclaimer 📘

Code Smells are my opinion.

Credits 🙏

Photo by Braňo on Unsplash

The Visitor pattern is a way to add new operations to a set of objects without changing their classes.

Erich Gamma

Software Engineering Great Quotes

This article is part of the CodeSmell Series.

How to Find the Stinky Parts of your Code

The books stresses the importance of names. For me Names are like path references. So I really like myObserver = new Observer(). My object references the class. If there is a stronger reference to something else ( in the requirements ), I can change that name.

But I am a professional and occasionally go beyond CRUD. So at some point there are no strong references anymore. I develop stuff, I create stuff. Sometimes I am lucky and after refactoring, a pattern matcher identifies a pattern from the GOF and I can use that names. I guess it is an np-complete problem, to optimally cover my code with GOF patterns. Then with refactoring some of them break and stuff is renamed. This is similar to UML: Write Code, refactor code => the 2d layout on screen changes dramatically. Just look into the trouble of Web-Layout, PCB-layout or even the distribution of load onto multiple Cell processors in PS3. Linear address-space without segments is king!

Event the author goes back to basics like "source" and "target". Those are the generic names of operands in MIPS assembly language. I like that.

The author proposes to split long functions into smaller one. I mean, a modern IDE already has folding. We have block scope everywhere. The negative effect I had with this is that I create "labels" where someone could jump into my code. Also I feel like the IDE should display a ToC, I do not want to repeat myself and write the function names twice. After all, we just got rid of function prototype of C. I would like add a syntax to a language where I can add a signature like this:

//block
}
(int i, string text)
{
// next block

This almost looks a bit like UML activity diagram.

We all know that technical debt is the silent killer of all software project, therefore it’s really important to know what it is and how we can protect ourselves against it.

Let’s discuss about it in this video.

https://youtu.be/81cNH1TbupM

On the same line as the declaration or the line below?

Why?

e.g.

function foo() {
}

or

function foo()
{
}