Your code smells because there are likely many instances where it could be edited or improved.
Most of these smells are just hints of something that might be wrong. Therefore, they are not required to be fixed per se… (You should look into it, though.)
You can find all the previous code smells (Part I - XLII) here.
Let's continue...
TL;DR: Don't use Tabs. It is not a "personal style decision"
1. Use spaces. Always.
2. Use automatic tools to prevent tabs in the code.
Developers might see using tabs or spaces for indentation as a matter of personal preference or team convention.
it is generally recommended towith the chosen method of indentation within a project.
There are a few advantages of using spaces over tabs.
Spaces will always look the same, no matter the text editor, font spacing, or IDE used.
Tabs can vary in width, which can lead to inconsistent indentation when code is viewed on different platforms or in different editors.
Spaces are more consistent in terms of alignment and readability, particularly when it comes to code that involves a mix of spaces and tabs.
Spaces are more predictable and easier to read, which can help to reduce errors in code.
Some screen readers and other assistive technologies may have difficulty reading code that uses tabs for indentation, particularly when tabs are used inconsistently or when tab width is not uniform.
def calculate_average(numbers):
total = 0
count = 0
for number in numbers:
total += number
count += 1
average = total / count
return average
numbers = [1, 2, 3, 4, 5]
print("The average is:", calculate_average(numbers))
def calculate_average(numbers):
total = 0
count = 0
for number in numbers:
total += number
count += 1
average = total / count
return average
numbers = [1, 2, 3, 4, 5]
print("The average is:", calculate_average(num
[X] Automatic
We can enforce a policy to avoid tabs.
Bad indentation can make the code difficult to read and understand and can cause errors if the indentation is not consistent throughout the code.
Using spaces for indentation is generally recommended for consistency, readability, and accessibility.
Code Smell 164 - Mixed Indentations
Code Smell 48 - Code Without Standards
Photo by Faisal Waheed on Unsplash
It is hard to write even the smallest piece of code correctly.
Joshua Bloch
Your code is not safer using this operator
TL;DR: Don't propagate nulls.
The Elvis operator is also known as the null-coalescing operator or the null-safe operator.
It is a shorthand operator used in some programming languages to simplify null-checking.
The Elvis operator takes the form of ?. and is used to access a property or method of an object only if that object is not null.
If the object is null, the operator returns null without attempting to access the property or method, thus avoiding a potential null reference exception.
The nickname "Elvis operator" originated from the visual resemblance of the operator to the famous singer Elvis Presley's hairstyle.
The symbol "?:", with its round shape on top and a curl underneath, vaguely resembles the pompadour hairstyle that Elvis Presley was known for.
val shipTo = address?: "No address specified"
val shipTo = if (address != null) address else "No address specified"
// This keeps the billion-dollar mistake error
We can detect this operator usage and replace them with more strict checks.
The code can be difficult to follow and may require additional comments or explanations to make it clear what is happening.
The operator hides potential errors or bugs in the code.
For example, if an object is null and the Elvis operator is used to return a default value, this may mask the fact that there is a problem with the code that is causing the object to be null in the first place.
In several languages, such as Common Lisp, Clojure, Lua, Object Pascal, Perl, Python, Ruby, and JavaScript, the OR operator (typically || or or) has the same behavior as the above: returning its first operand if it would evaluate to true in a boolean environment, and otherwise evaluating and returning its second operand.
When the left-hand side is true, the right-hand side is not even evaluated; it is "short-circuited." This is different from the behavior in other languages such as C/C++, where the result of || will always be a boolean.
Code Smell 149 - Optional Chaining
Code Smell 06 - Too Clever Programmer
Code Smell 140 - Short Circuit Evaluation
Null: The Billion Dollar Mistake
Photo by Susan Mohr on Unsplash
You can't communicate complexity, only an awareness of it.
Alan Perlis
You can prevent undefined
TL;DR: Declare your variables and look after the scope
Hoisting allows variable declarations to be moved to the top of their containing scope during the compilation phase.
Variables declared with var and function declarations are "hoisted" to the top of their respective scopes automatically in several languages.
console.log(willBeDefinedLater);
// Output: undefined (but no error)
var willBeDefinedLater = "Beatriz";
console.log(willBeDefinedLater);
// Output: "Beatriz"
const dante = "abandon hope all ye who enter here";
// Declaring a constant 'dante'
// with value "abandon hope all ye who enter here"
console.log(dante);
// Output: "abandon hope all ye who enter here"
dante = "Divine Comedy"; // Error: Assignment to constant variable
We can perform mutation testing to check if changing the scope of the variables brings unexpected results.
Hoisting is yet another magic tool some compilers provide to favor lazy programmers.
But if it fights back in debugging time.
Code Smell 116 - Variables Declared With 'var'
Code Smell 42 - Warnings/Strict Mode Off
Photo by Ash from Modern Afflatus on Unsplash
The best error message is the one that never shows up.
Thomas Fuchs
Two arguments of the same type. Two equal names
TL;DR: Turn on Strict Checks
Most compilers forbid duplicate parameters since they are a common mistake in a large parameters list
function addNumbers(a, b, a) {
console.log(a + b);
}
addNumbers(2, 3, 4);
// Outputs 7 (2 + 3 + 2)
"use strict";
function addNumbers(a, b, a) { }
// ^
// SyntaxError: Duplicate parameter name not allowed in this context
By enabling strict mode, the compiler will warn us
Enable the stricter modes you can find on your compilers.
Try to fail fast and catch errors as early as possible and leave the hard and dumb work to the tools.
Code Smell 188 - Redundant Parameter Names
Code Smell 65 - Variables Named after Types
Photo by Caroline Veronez on Unsplash
One of the things I've been trying to do is look for simpler or rules underpinning good or bad design. I think one of the most valuable rules is avoiding duplication. "Once and only once" is the Extreme Programming phrase.
Martin Fowler
Metaprogramming is always a problem
TL;DR: Don't allow remote code execution
Deserializing objects from an untrusted source is indeed a security-sensitive operation.
Suppose you have a web application that accepts serialized objects as input from user-submitted data, such as in an API endpoint or a file upload feature.
The application deserializes these objects to reconstruct them into usable objects within the system.
If an attacker submits maliciously crafted serialized data to exploit vulnerabilities in the deserialization process.
They might manipulate the serialized data to execute arbitrary code, escalate privileges, or perform unauthorized actions within the application or the underlying system.
This type of attack is commonly known as "deserialization attacks" or "serialization vulnerabilities."
import pickle # Python's serialization module
def process_serialized_data(serialized_data):
try:
obj = pickle.loads(serialized_data)
# Deserialize the object
# Process the deserialized object
# ...
# User-submitted serialized data
user_data = (
b"\x80\x04\x95\x13\x00\x00\x00\x00\x00\x00\x00\x8c\x08os\n"
b"system\n\x8c\x06uptime\n\x86\x94."
)
# This code executes os.system("uptime")
process_serialized_data(user_data)
import json
def process_serialized_data(serialized_data):
try:
obj = json.loads(serialized_data)
# Deserialize the JSON object
# Does not execute code
# ...
user_data = '{"key": "value"}'
process_serialized_data(user_data)
Several linters warn about deserialization points.
Metaprogramming opens doors to abusers.
Code Smell 189 - Not Sanitized Input
Photo by Towfiqu barbhuiya on Unsplash
Whenever possible, steal code.
Tom Duff
Next week, 5 more smells