Suppose we have received a response from an API call, with following structure:
response = {
"data": {
"id": 241332,
"recipient": {
"city": "Palo Alto",
"country": "US",
"address": "1 Infinite Loop",
"postal_code": "12345",
"state": "CA",
"name": "Tim Cook",
"phone": "+1234567890",
"email": "tcook@apple.com"
},
"cost": 1099.00,
"currency": "USD",
"name": "Google Pixel 7 Pro",
"quantity": 1,
"color": "Obsidian",
"capacity": "512GB"
}
}
Our goal is to retrieve the email of the recipient. We assume that any field may be missing to add complexity.
The LBLY states that you should check for preconditions before performing any actions (like calling functions, accessing dictionary keys, or object attributes).
Just like this:
def get_user_email(response: dict) -> str | None:
data = response.get('data')
if data:
recipient = data.get('recipient')
if recipient:
return recipient.get('email')
return None
This approach is the most commonly used in programming, but it can also result in a lot of repetitive and unnecessary code, which can be challenging to maintain. So, why not attempt to access the key and handle the exception if it doesn’t exist? This is precisely where EAFP comes into play.
The EAFP states that it’s simpler to perform an action and then handle error, instead of checking all necessary conditions beforehand.
Example:
def get_user_email(response: dict) -> str | None:
try:
return response['data']['recipient']['email']
except KeyError:
return None
One essential thing to bear in mind is that we should always catch the most specific exception available. In this
example, we are catching a KeyError exception, which is raised when a dictionary key is not found. If we catch a
general Exception we may inadvertently catch exceptions that we weren’t expecting, leading to unexpected behavior.
Neither of these approaches is superior to the other. Both approaches have their pros and cons, and the choice of which one to use and when ultimately depends on the specific requirements and context of the program.
That’s all for today. See you next time!
]]>This article is not meant to be SOLID-propaganda, and I’m not going to convince you that you are obligated to adhere to SOLID principles. My purpose is simple — to tell you what SOLID is and how it works. It’s up to you to apply these principles in your work or not. Anyway, after reading this article, you will be able to defend/hate SOLID with a frothing at the mouth.
In short, SOLID is a set of five principles of object-oriented design focused on making software more modular, maintainable, and scalable.
The acronym SOLID stands for:
Let’s examine each of these principles separately.
The Single Responsibility Principle (SRP) states that a class should have only one reason to change, meaning that it should have only one responsibility or task to perform. By following this principle, a class’s functionality is more focused, leading to improved manageability and comprehension.
First, let’s look at code which violates SRP:
class User:
def __init__(self, name: str, email: str, password: str) -> None:
self.name = name
self.email = email
self.password = password
def login(self) -> None:
print(f"Logging in user: {self}")
def logout(self) -> None:
print(f"Logging out user: {self}")
def send_notification(self, message) -> None:
print(f"Sending notification to {self}: {message}")
def serialize(self) -> None:
print(f"Serializing user: {self}")
It’s evident that the User class violates the SRP since it’s accountable for numerous tasks, namely:
If any one of these responsibilities changes, it may affect the entire User class. For instance, if the method for
sending notifications needs to be updated or changed, it could potentially break the code for the entire User
class, including the methods for logging in.
By following SRP, our goal is to separate the different responsibilities into their own classes, so that each class is
responsible for only one thing. For example, a User class could be responsible for storing user information only,
while separate Authentication, NotificationSender, and UserSerializer classes could be responsible for their
respective tasks.
Here’s an example of how we can refactor the User class to adhere to the SRP:
class User:
def __init__(self, name: str, email: str, password: str) -> None:
self.name = name
self.email = email
self.password = password
def __str__(self) -> str:
return f"{self.name} <{self.email}>"
def __repr__(self) -> str:
return f"User('{self.email}')"
class UserSerializer:
def __init__(self, user: User) -> None:
self.user = user
def serialize(self) -> None:
print(f"Serializing user: {self.user}")
class Authentication:
def login(self, user: User) -> None:
print(f"Logging in user: {user}")
def logout(self, user) -> None:
print(f"Logging out user: {user}")
class NotificationSender:
def send_notification(self, user: User, message: str) -> None:
print(f"Sending notification to {user}: {message}")
if __name__ == "__main__":
user = User(
"Winston Churchill",
"winston@churchill.uk",
"we-shall-fight"
)
# Authentication
auth = Authentication()
auth.login(user)
auth.logout(user)
# Notification
notification_sender = NotificationSender()
notification_sender.send_notification(
user, "Beware of the German U-boats!",
)
# Serialization
user_serializer = UserSerializer(user)
user_serializer.serialize()
As you can see, it’s pretty clear and I have nothing more to add here.
The Open/Closed Principle (OCP) states that a class should be open for extension but closed for modification. This means that we should be able to add new functionality to a class without changing its existing code.
Let’s examine the code that violates the OCP:
class NotificationService:
def __init__(self, notification: str) -> None:
self.notification = notification
def send_notification(self, message: str) -> None:
if self.notification == "email":
print(f"Sending email with message: {message}")
elif self.notification == "push":
print(f"Sending SMS with message: {message}")
elif self.notification == "slack":
print(f"Sending whatsapp with message: {message}")
if __name__ == "__main__":
notification_service = NotificationService("slack")
notification_service.send_notification("Hello World")
This code violates the OCP because the NotificationService class is not closed for modification. If we want to
add a new notification method, we have to modify the existing code in the send_notification method.
Let’s modify the code to follow to the OCP:
import abc
class Notification(abc.ABC):
@abc.abstractmethod
def send(self, message: str) -> None:
raise NotImplementedError
class PushNotification(Notification):
def send(self, message: str) -> None:
print("Sending push notification...")
class EmailNotification(Notification):
def send(self, message: str) -> None:
print("Sending email notification...")
class SlackNotification(Notification):
def send(self, message: str) -> None:
print("Sending slack notification...")
class NotificationService:
def __init__(self, notification: Notification) -> None:
self.notification = notification
def send_notification(self, message: str) -> None:
self.notification.send(message)
if __name__ == "__main__":
notification_service = NotificationService(SlackNotification())
notification_service.send_notification("German U-boats spotted!")
In this example, the NotificationService class is closed for modification because we can add new notification
methods without changing the existing code. For instance, if we want to add a new SMSNotification class, we can
simply create a new class that extends the Notification class and implement the send method. Such a design
allows us to add new notification methods without changing the existing code.
The LSP states that a subclass should be substitutable for its superclass without changing the correctness of the program. In other words, if we replace an instance of a superclass with an instance of its subclass, the program should still behave as expected.
Let’s take a look at the following example which violates the LSP:
import abc
class ICharacter(abc.ABC):
@abc.abstractmethod
def greet(self) -> None:
raise NotImplementedError
class Human(ICharacter):
def greet(self) -> None:
print("Hello, I am a human")
class Polish(Human):
def greet(self) -> None:
print("Dzień dobry, kurwa!")
class French(Human):
def greet(self) -> None:
print("Bonjour!")
class German(Human):
def greet(self) -> None:
raise RuntimeError("Nien!")
In this example, the German class is a subclass of Human. However, it violates the LSP because it
changes the behavior of the German. The Human class can greet, but the German class cannot. This means
that code that expects a Human instance may behave unexpectedly or fail when given a German instance.
Let’s refactor code to make it follow LSP:
import abc
class ICharacter(abc.ABC):
@abc.abstractmethod
def greet(self) -> None:
raise NotImplementedError
class Human(ICharacter):
def greet(self) -> None:
print("Hello, I am a human")
class Polish(Human):
def greet(self) -> None:
print("Dzień dobry, kurwa!")
class French(Human):
def greet(self) -> None:
print("Bonjour!")
class German(Human):
def greet(self) -> None:
print("Hallo!")
The Interface Segregation Principle (ISP) states that a class shouldn’t be forced to depend on methods it does not use. In other words, we should break down large interfaces into smaller ones, more focused on the needs of each class.
Let’s take a look at the following example which violates the ISP:
import abc
class ICharacter(abc.ABC):
@abc.abstractmethod
def attack(self) -> None:
raise NotImplementedError
@abc.abstractmethod
def walk(self) -> None:
raise NotImplementedError
@abc.abstractmethod
def pull_out_rpg(self) -> None:
raise NotImplementedError
class Warrior(ICharacter):
def attack(self) -> None:
print("Warrior is attacking")
def walk(self) -> None:
print("Warrior is walking")
def pull_out_rpg(self) -> None:
print("Pulling out motherfucking RPG-7")
class Civilian(ICharacter):
def pull_out_rpg(self) -> None:
# Jesus Christ, what kind of civilian is this?
# Where the hell did this bastard get a thermoboric RPG shell?
print("Pulling out motherfucking RPG-7 with thermobaric shell")
def attack(self) -> None:
# Why the hell would a civilian attack?
print("Civilian is attacking")
def walk(self) -> None:
print("Civilian is walking")
In this example, we define an ICharacter interface that has three methods:
attack()walk()pull_out_rpg()We have a violation of the ISP in the implementation of the ICharacter interface, where we
define two concrete classes Warrior and Civilian. The problem is that Civilian is forced to implement the attack
and pull_out_rpg methods, even though it may not (haha) need to use them.
If we don’t implement these methods in the Civilian class, we’ll get an error:
TypeError: Can't instantiate abstract class Civilian with abstract methods attack, pull_out_rpg
To avoid such problems, it’s highly recommendable to break down large interfaces into smaller ones, more focused on the needs of each class. Let’s refactor the code to make it follow ISP:
import abc
class ICharacter(abc.ABC):
@abc.abstractmethod
def walk(self) -> None:
raise NotImplementedError
class IWarrior(ICharacter):
@abc.abstractmethod
def attack(self) -> None:
raise NotImplementedError
@abc.abstractmethod
def pull_out_rpg(self) -> None:
raise NotImplementedError
class Warrior(IWarrior):
def attack(self) -> None:
print("Warrior is attacking")
def walk(self) -> None:
print("Warrior is walking")
def pull_out_rpg(self) -> None:
print("Pulling out motherfucking RPG-7")
class Civilian(ICharacter):
def walk(self) -> None:
print("Civilian is walking")
Now we no longer arm civilians with hand-held anti-tank grenade launchers, and the world is a little safer.
The Dependency Inversion Principle (DIP) states that high-level classes should not depend on low-level classes. Instead, they should both depend on abstractions. Abstractions should not depend on details, but details should depend on abstractions.
Let’s examine DIP violation:
class StripePaymentGateway:
def pay(self) -> None:
print("Paying with Stripe")
class KlarnaPaymentGateway:
def pay(self) -> None:
print("Paying with Klarna")
class BitPayPaymentGateway:
def pay(self) -> None:
print("Paying with BitPay")
class PaymentProcessor:
def __init__(self) -> None:
self.stripe = StripePaymentGateway()
self.klarna = KlarnaPaymentGateway()
self.bitpay = BitPayPaymentGateway()
def process_payment(self, payment_gateway: str) -> None:
if payment_gateway == "stripe":
self.stripe.pay()
elif payment_gateway == "klarna":
self.klarna.pay()
elif payment_gateway == "bitpay":
self.bitpay.pay()
if __name__ == "__main__":
payment_processor = PaymentProcessor()
payment_processor.process_payment('stripe')
payment_processor.process_payment('klarna')
payment_processor.process_payment('bitpay')
In this example, we have a PaymentProcessor class which has a hard dependencies on concrete implementations of payment
gateways. This is a violation of the DIP because the PaymentProcessor class is a high-level class that depends on
low-level classes. This means that if we want to add a new payment gateway, we’ll have to modify the PaymentProcessor
class which potentially can break the code.
Let’s refactor our payment gateway to make it follow DIP:
import abc
class PaymentGateway(abc.ABC):
@abc.abstractmethod
def pay(self) -> None:
raise NotImplementedError
class StripePaymentGateway(PaymentGateway):
def pay(self) -> None:
print("Paying with Stripe")
class KlarnaPaymentGateway(PaymentGateway):
def pay(self) -> None:
print("Paying with Klarna")
class BitPayPaymentGateway(PaymentGateway):
def pay(self) -> None:
print("Paying with BitPay")
class PaymentProcessor:
def __init__(self, payment_gateway: PaymentGateway) -> None:
self.payment_gateway = payment_gateway
def pay(self) -> None:
self.payment_gateway.pay()
if __name__ == "__main__":
payment_processor = PaymentProcessor(StripePaymentGateway())
payment_processor.pay()
payment_processor = PaymentProcessor(KlarnaPaymentGateway())
payment_processor.pay()
payment_processor = PaymentProcessor(BitPayPaymentGateway())
payment_processor.pay()
In this example, we have a PaymentProcessor class that depends on an abstraction PaymentGateway. This means that we
can add as many payment gateways as we want without modifying the PaymentProcessor class itself.
In this article, we have explored the SOLID principles and their implementation in Python. We have discussed how the SRP can help in creating more organized and manageable classes, and how the OCP can make our code more extensible. We have also examined the LSP to achieve more flexible code, the ISP for maintainable code, and even had a bit of fun disarming civilians. Finally, we have explored how the DIP can increase code reusability.
That’s all for today. See you next time!
If you’re familiar with Python, you might have heard of secrets module from Python’s standard library. Basically, the secrets.clj is just like Python’s secrets, but for Clojure — it’s a library designed to generate cryptographically strong random numbers suitable for managing data such as passwords, account authentication, security tokens, and related secrets.
Add secrets.clj to your project.clj file:
[likid_geimfari/secrets "2.1.1"]
then run lein deps to install it.
That’s it, you’re ready to go:
(ns example.core
(:require [secrets.core]
[secrets.tools]
[secrets.constants]))
Typical use cases are:
Generates a random integer with k random bits.
Example:
user=> (secrets.core/randbits 32)
1530556122
This function generates a secure random integer in the range [0, n), where n is the exclusive upper bound.
Example:
user=> (secrets.core/randbelow 9999)
34
This function returns a random element from a non-empty sequence or throws an exception if the sequence is empty.
user=> (secrets.core/choice ["bob" "alice" "eve"])
"eve"
Just like secrets.core/choice, but this function returns a list of random elements picked from the sequence:
(secrets.core/choices ["bob" "alice" "eve"] 2)
("eve" "alice")
Generates a secure random string in hexadecimal format. The string has nbytes random bytes, and each byte is converted to two hex digits.
If n-bytes are not supplied, a reasonable default gets used, which is 32.
user=> (secrets.core/token-hex 64)
"3a3e8e6636000dd3b7d39aa4316935f27c2f013d768f0c00f309efb453f34dbc673060db2cd8af288494892848"
Generates a secure random string in URL-safe format.
(defn generate-password-recovery-url [n]
(str "https://mydomain.com/reset=" (secrets.core/token-urlsafe n)))
(generate-password-recovery-url 64)
"https://mydomain.com/reset=TItm04q8by00MRMcNBt7I3Yx-wSxyUa79isRLNyQJCd8K75RnqUahwcWA_rURBt1clknJiRGrubapGaUrEUnSw"
Generates a secure random string in bytes format.
(secrets.core/token-bytes 16)
#object["[B" 0x3b2454e9 "[B@3b2454e9"]
To be secure against brute-force attacks, tokens need to have sufficient randomness. The number of random bits needed for a token depends on the application, but 256 bits is considered to be cryptographically strong.
Personally, I would recommend using 64 bytes (512 bits).
Table of content:
pytest is a framework that makes it easy to write small tests, yet scales to support complex functional testing for applications and libraries.
Features
unittest and nose test suites out of the box;Python 3.5+ and PyPy 3;Hypothesis is a family of testing libraries that let you write tests parametrized by a source of examples. A Hypothesis implementation then generates simple and comprehensible examples that make your tests fail. This simplifies writing your tests and makes them more powerful at the same time, by letting software automate the boring bits and do them to a higher standard than a human would, freeing you to focus on the higher-level test logic.
Robot Framework is a generic open-source automation framework for acceptance testing, acceptance test-driven development (ATDD), and robotic process automation (RPA). It has simple plain text syntax and it can be extended easily with libraries implemented using Python or Java.
unittest is a unit testing framework from Python’s stdlib, which was originally inspired by JUnit and has a similar flavor as major unit testing frameworks in other languages. It supports test automation, sharing of setup and shutdown code for tests, aggregation of tests into collections, and independence of the tests from the reporting framework.
tox is aims to automate and standardize testing in Python. It is part of a larger vision of easing the packaging, testing and release process of Python software.
tox is a generic virtual environment management and test command line tool you can use for:
Selenium is an umbrella project encapsulating a variety of tools and libraries enabling web browser automation. Selenium specifically provides an infrastructure for the W3C WebDriver specification — a platform and language-neutral coding interface compatible with all major web browsers.
Locust is an easy to use, scriptable, and scalable performance testing tool. You define the behavior of your users in regular Python code, instead of using a clunky UI or domain-specific language. This makes Locust infinitely expandable and very developer-friendly.
TestCafe is a Node.js tool to automate end-to-end web testing. Write tests in JS or TypeScript, run them, and view results.
npm install -g testcafePyAutoGUI is a cross-platform GUI automation Python module for human beings. Used to programmatically control the mouse & keyboard.
Mimesis is a high-performance fake data generator for Python, which provides data for a variety of purposes in a variety of languages. The fake data could be used to populate a testing database, create fake API endpoints, create JSON and XML files of arbitrary structure, anonymize data taken from production and etc.
The key features are:
unittest.mock is a library from Python’s stdlib for mocking. It allows you to replace parts of your system under test with mock objects and make assertions about how they have been used.
unittest.mock provides a core Mock class removing the need to create a host of stubs throughout your test suite.
After performing an action, you can make assertions about which methods / attributes were used and arguments they
were called with. You can also specify return values and set needed attributes in the normal way.
FreezeGun is a library that allows your Python tests to travel through time by mocking the datetime module.
Once the decorator or context manager have been invoked, all calls to datetime.datetime.now(),
datetime.datetime.utcnow(), datetime.date.today(), time.time(), time.localtime(), time.gmtime(), and time.strftime()
will return the time that has been frozen.
HTTPretty is an HTTP client mocking tool for Python - inspired by Fakeweb for Ruby.
Common use cases:
Coverage.py measures code coverage, typically during test execution. It uses the code analysis tools and tracing hooks provided in the Python standard library to determine which lines are executable, and which have been executed.
factory_boy is a fixtures replacement based on thoughtbot’s factory_bot.
As a fixtures replacement tool, it aims to replace static, hard to maintain fixtures with easy-to-use factories for complex objects.
wemake-python-styleguide is is strictest and most opinionated python linter ever.
Goals of WPS:
Python 3.6+ usagepycodestyle is a tool to check your Python code against some of the style conventions in PEP8.
Features:
stdlib. You can use just the pycodestyle.py file for this purpose.Black is the uncompromising Python code formatter. By using it, you agree to cede
control over minutiae of hand-formatting. In return, Black gives you speed,
determinism, and freedom from pycodestyle nagging about formatting. You will save time
and mental energy for more important matters.
yapf is a formatter for Python files.
YAPF takes a different approach. It’s based off of clang-format, developed by Daniel Jasper. In essence,
the algorithm takes the code and reformats it to the best formatting that conforms to the style guide, even if the
original code didn’t violate the style guide. The idea is also similar to the ‘gofmt’ tool for the Go programming
language: end all holy wars about formatting - if the whole codebase of a project is simply piped through YAPF
whenever modifications are made, the style remains consistent throughout the project and there’s no point
arguing about style in every code review.
mypy is an optional static type checker for Python. You can add type
hints (PEP 484) to your Python programs, and use mypy to type check them statically. Find bugs in your
programs without even running them!
Here is a small example to whet your appetite (Python 3):
from typing import Iterator
def fib(n: int) -> Iterator[int]:
a, b = 0, 1
while a < n:
yield a
a, b = b, a + b
Pyre is a performant type checker for Python compliant with PEP 484. Pyre can analyze codebases with millions of lines of code incrementally – providing instantaneous feedback to developers as they write code.
Pyre ships with Pysa, a security-focused static analysis tool we’ve built on top of Pyre that reasons about data flows in Python applications. Please refer to our documentation to get started with our security analysis.
Typeshed contains external type annotations for the Python standard library and Python builtins, as well as third party packages as contributed by people external to those projects.
django-stubs contains type stubs and a custom mypy plugin to
provide more precise static types and type inference for Django framework. Django uses some Python “magic”
that makes having precise types for some code patterns problematic. This is why we need this project. The final goal
is to be able to get precise types for most common patterns.
returns gonna make your functions return something meaningful, typed, and safe!
Features:
mypy, PEP561 compatibleThat’s it for now!
]]>is and == without knowing how
exactly they work and when to use each one. In this article, I’ll talk about the difference between
them, and about the use cases of each one.
Spoiler: the main difference is that is compares IDs of objects to check if both the operands
refer to the same object and cannot be overloaded, when == compares the values of the objects
and can be overloaded using the magic method __eq__.
Have a look at this code:
>>> a = []
>>> b = []
>>> a == b # a.__eq__(b)
True
>>> a is b
False
That’s right a is not b, and here is why:
>>> a_id = id(a)
4464140992
>>> b_id = id(b)
4465176960
>>> a_id == b_id
False
Using operator is makes sense when you want to compare variable with a singleton-object,
like None, Ellipsis and so on:
Good:
if some_object is Ellipsis:
do_some_stuff()
Still, good:
if some_object is not None:
do_other_stuff()
Bad (even it will work correctly, because None always equal to None):
if some_object == None:
do_some_stuff()
It’s better to write it like this:
if not some_object:
do_some_stuff()
or like this:
if some_object is None:
do_some_stuff()
Using operator == makes sense when you interested in comparing the values of objects:
>>> a = []
>>> b = []
>>> a == b # [].__eq__([])
True
>>> c = 'isaak'
>>> d = 'Isaak'
>>> c == d.lower()
Keep in mind, that by default the magic method __eq__ inherited from object compares
IDs of objects (because it knows nothing about values).
You can read more about __eq__ here.
is when you compare variable with a singleton-object.== when you want to compare the values of the objects.In this article, we will discuss code that is the exact opposite of what we just described - code that was written carelessly or thoughtlessly. This article is a small confession, because like any other programmer, I have also written such code in the past (in fact, I still write bad code sometimes, although refactoring makes it much better). This is nothing terrible as long as we understand that we need to work on it.
This article is a translated version of my article from harb.com so, if you know Russian then you can read the original version.
Let’s start.
One of the most annoying types of variables are those that give a false impression of the nature of the data they store.
The requests library is extremely popular among Python developers, and if you have ever looked for anything
related to requests, you must have come across something like this:
import requests
req = requests.get('https://api.example.org/endpoint')
req.json()
Whenever I see this, I feel annoyed, not only because of the shortened name but also because the variable’s name does not match what is stored in it.
When you make a request (requests.Request), you get a response (requests.Response),
so reflect this in your code:
response = requests.get('https://api.example.org/endpoint')
response.json()
Not r, not res, not resp and certainly not req, exactly response. res, r, resp – these are all
variables whose contents can be understood only by looking at their definitions, and why jump to the definitions
when you can initially give a suitable name?
Let’s look at another example, but now from Django:
users_list = User.objects.filter(age__gte=22)
When you see users_list somewhere in the code, you quite rightly expect that you can do this:
users_list.append(User.objects.get(pk=3))
but no, you can’t do this, since .filter() returns a QuerySet:
Traceback (most recent call last):
# ...
# ...
AttributeError: 'QuerySet' object has no attribute 'append'
If it is very important for you to specify a suffix, then specify at least one that reflects the real situation:
users_queryset = User.objects.all()
users_queryset.order_by('-age')
also okay, because such abbreviations (_qs) are usual for Django:
users_qs = User.objects.all()
If you really want to write exactly _list, then take care that the list really gets into the variable:
users_list = list(User.objects.all())
Indicating a type of data that a variable contains is often a bad idea, especially when you deal with dynamic languages, such as Python. In cases when it is very necessary to note that the object is a container data type, it is enough to simply indicate the name of the variable in the plural:
users = User.objects.all()
Consider another example:
info_dict = {'name': 'Isaak', 'age': 25}
# ...
# ...
info_dict = list(info_dict)
# ...
# ...
You see a dict and you might want to do this:
for key, value in info_dict.items():
print(key, value)
Instead, you’ll get an exception, because you were misled, and you will understand this only if you go to the definition of the variable and read the entire code from top to bottom, right down to the section from which you started the jump — this is the price of such variables.
Thus, when you indicate in the variable name the type of data stored in it, you are essentially a guarantee that this variable must contain the specified data type at any time during the execution of the program. Why should you take this responsibility if it is the direct responsibility of the interpreter or compiler? You shouldn’t! Better to spend time thinking of a good variable name than trying to figure out why the variables do not behave as you expect.
In the example above, the choice of the name of a variable is rather bad, and you could give a name that more accurately expresses the context (no need to be afraid to use the domain-specific names), but even in this case, you could make this code better:
info_dict = {'name': 'Isaak', 'age': 25}
# ...
# ...
info_keys = list(info_dict)
# ...
# ...
or even like this, which is more idiomatic:
info_dict = {'name': 'Isaak', 'age': 25}
# ...
# ...
info_keys = info_dict.keys()
# ...
# ...
Another type of annoying variable is ones with a shortened name.
Let’s go back to requests and consider this code:
s = requests.Session()
# ...
# ...
s.close()
This is an example of an unnecessary shortening for a variable name. This is a terrible practice, and its horror becomes even more apparent when such code takes up more than 10-15 lines of code.
It is much better to write as is, namely:
session = requests.Session()
# ...
# ...
session.get('https://api.example.org/endpoint')
# ...
# ...
session.close()
or
with requests.Session() as session:
session.get('https://api.example.org/endpoint')
You may argue that this is a more verbose option, but I will answer you that it pays off when
you read the code and immediately understand that session is a Session.
Will you understand it by variable s without looking at its definition?
Smart naming of functions and methods is something that comes only with experience in designing an API, and therefore you can often find cases where methods do not behave as you expect.
Consider an example:
>>> person = Person()
>>> person.has_publications()
['Post 1', 'Post 2', 'Post 3']
We expressed a very clear-cut question in our code: “Does this person have publications?”, but what kind of answer did we get? Did we ask for a list of publications of a person?
The name of this method implies that the return value must be of Boolean type, namely True or False:
>>> person = Person()
>>> person.has_publications()
True
We can use a more appropriate method name for getting publications:
>>> person.get_publications()
['Post 1', 'Post 2', 'Post 3']
or
>>> person.publications()
['Post 1', 'Post 2', 'Post 3']
We often like to call programming a creative activity, and it really is. However, if you write not readable code, and then justify it with “creativity”, then I have bad news for you.
I’m leaving this list of outstanding relevant literature written by well-known professionals in the field for further study of the issue:
A good comment takes time to think and write, and therefore most often we all come across disgusting comments that are nothing but a piece of visual garbage.
Let’s consider a small example from JavaScript:
// Remove first five letters
const errorCode = errorText.substr(5)
The first thought that flashes in your head when you see this is “Thank you, cap!”. Why should we describe things that are already clear without comment? Why should we duplicate the information that the code already tells us?
This distinguishes a good comment from a bad one - a good comment makes you feel grateful for the developer who wrote it when a bad comment just annoys you as hell.
Let’s try to make this comment a little useful:
// Remove "net::" from the error text
const errorCode = errorText.substr(5)
Better yet, resort to a more declarative approach and opt-out the comment:
const errorCode = errorText.replace('net::', '')
Dead code, perhaps, is much more annoying than useless comments, since you also have to figure out was the code commented out temporarily (to debug some parts of the system or something), or did the developer just forget to delete it?
Be that as it may, dead code has no place in the modules and it should be deleted! If it suddenly turns out that this was something important, then you can just roll back to the correct version (unless, of course, you are something like an Amish programmer that does not use the version control system).
]]>I will mainly write on this blog about software development in terms of my
main programming languages, i.e Python and JavaScript.
Also, I’m going to write here about the programming languages and technologies I learn.
At this moment my main interest is Rust, Erlang/Elixir and Clojure.
So, that’s it.
You can read more about me here.
P.S I’m not a native English speaker, so I hope my readers will treat my grammar mistakes with patience and understanding.
]]>