DEV Community: Paul AJadi

Writing Clean, Efficient, and Maintainable Code - Python as use case.

Paul AJadi — Thu, 26 Sep 2024 13:29:40 +0000

Writing Clean, Efficient, and Maintainable Code - Python as use case.
If you have been a developer for some time, you may understand the importance of proper coding as against the rush of just writing somthings that works. One of the greatest setback this has for you is when you need to review your code you rarely can make sense of what you were trying to do and for others, they have a hard time reading your code.

I recently have been reviewing some codes and I think it is important to stress the need to clean, efficien code.

Some history to guidelines and styles in coding

In the early 1970's when the C Programming language was gaining popularity coding style become a matter of discussion and two notable names around this were Brian Kernighan and Dennis Ritchie.

Interestingly, Ada language enforced strict coding guidelines and standards in the rearly 1980's. Mid 1990's Python and Java came in with strong coding conventions from the initial phase and Python Enhancement Proposal (PEP 8) was well adopted which today is still a valid coding convention.

PEP 8 Guidelines for Code Styling: I have used this guideline everynow and then and I have seen other programmers adopt this.

VS Code's flake8 code linting extension is a great choice I use.
The guidelines are:
Indentation: Use 4 spaces per indentation level.
Line Length: Limit all lines to a maximum of 79 characters.
Naming Conventions: Use snake_case for function and variable names and CamelCase for class names.

For example:

`# defining variables using snake_case

total_price = 100
customer_email = "customer@example.com"

# defining functions using snake_case
def calculate_total_price():
    pass

class OrderManager:
    pass`

2. Meaningful comments and documentations: Docstrings helps developers understand a function/methods purpose, paramters and return values. It is generally good practice to introduce them and writing comments to clarify a complex logic or decision
For example:

def calculate_total_price(price: float, quantity: int) -> float:
    """
    Calculate the total price of items.

    Args:
        price (float): The price of a single item.
        quantity (int): The number of items purchased.

    Returns:
        float: The total price.
    """
    return price * quantity

**3. Code Repititions: **As a simply rule of thumb avoid repeating a code that's already implemented, instead follow the DRY principle by making reusable functions. The caveat to this is, when a new developer implements a change, the developer might not know there is a duplicated code that has been left out and can mess with a whole lot owing to this error.

For example, you have a function that calculates total price for an ecommerce store by multiplying the price and quantity.

total_price_laptops = 1000 * 2
total_price_phones = 500 * 3
This, is easily done with reusable functions like this:
def calculate_total(price, quantity):
    return price * quantity

total_price_laptops = calculate_total(1000, 2)
total_price_phones = calculate_total(500, 3)

4. Type Hints: Python is dynamically typed language, type hinting your code improve readability and catch errors early. It is easier to understand what data types are expected.

For example:

def get_discounted_price(price: float, discount: float) -> float:
    return price - (price * discount)

**5. Writing Tests: **Tests validate the functionality of your code. Popular frameworks like unittest or pytest make writing and running tests simple. Testing asserts that your code behaves as expected, reducing the risk of introducing bugs when making changes or refactoring.

def test_calculate_total_price():
    assert calculate_total_price(100, 2) == 200

6. Exceptions: It can be embarassing when production codes print out lines of meaninglesss code to client users or even worse, output environmental variables. Avoiding this is easier with exception try/except/finally handling to manage predictable errors and ensure your application doesn't crash unexpectedly.

try:
    value = int(input("Enter a number: "))
except ValueError:
    print("That's not a valid number!")
finally:
    print('Thank you!')

7. Code Modularization: There is no rule that says to keep your codes in one file. Break down large blocks of code into smaller, reusable modules and import them across the application where neede. It is easier to test and update.

8. Version Control: Version control systems like Git is a fundamental best practice in modern development. Others are Beanstalk, PerForce, Apache subversion. Version controls can track changes, reduce human errors during collaborations and unintended consequences to a great extent.

By following best practices like adhering to PEP 8, keeping your code DRY, writing meaningful documentation, and handling exceptions gracefully, you can ensure that your Python projects are professional, scalable, and easy to maintain.
Start implementing these tips today, and you'll see a noticeable improvement in the quality of your code.

Understanding Database Normalization: A Practical Guide with E-Commerce Examples

Paul AJadi — Sat, 14 Sep 2024 17:59:53 +0000

In database design, one of the most fundamental and basic concepts is normalization. It gets confusing at some point, and it has taken some time for me to grasp how to normalize a database through recurrent practice.

The primary goal of normalization, I believe, is to eliminate redundancy and ensure data integrity. In the end, normalization leads to efficient data retrieval and simplifies database maintenance.

What is Database Normalization?

Database normalization involves structuring a relational database to reduce repetitive data/redundancy and improve data integrity. It's typically done by splitting large tables into smaller tables, related using foreign keys, which ensures that data is stored only once.

Normalization is carried out through a series of stages/normal forms. Each form introduces more rules and restrictions to further organize the data.
There are five major normal forms (1NF - 5NF), but in practice, the first three normalize a database in a real-world scenario.

Why is normalization important?

Normalizing databases helps avoid these anomalies, especially with systems that perform CRUD operations:

Data redundancy:

Repititing the same data in multiple places (1 or more tables).
Update anomalies: Owing to having multiple entries, it poses difficulty updating redundant data in multiple places and can lead to inconsistency with data.
Insert/Delete anomalies: You cannot trust adding or removing certain data without having other entries already present.

Normal Forms Overview

Normalization is done in forms/stages, each referred to as a normal form.
First

Normal Form (1NF): Ensures each column contains indivisible values and that there are no repeating groups. This is called ATOMICITY
Second Normal Form (2NF): Builds on 1NF, ensuring that all non-key attributes are fully dependent on the primary key.
Third Normal Form (3NF): Ensures that non-key attributes are not only dependent on the primary key but also independent of each other.

Normalization in an E-commerce Database: An Example

Let us consider a basic e-commerce system where customers place orders for products. I usually will advise having all required fields written out on a pen or a wordpad.
An initial database structure would look like this:
Unnormalized Table or the Flat Structure

CustomerName (varchar), CustomerEmail (varchar), ProductID (varchar), quantity, price (decimal), orderdate (date), etc

The Three Normal Forms

First Normal Form (1NF): Eliminate Repeating Groups A table is in 1NF when: All columns contain

atomic (indivisible) values.
Each record has a unique identifier, known as a primary key.

Example:

Table 1

Table 2

Consider the two tables above:
Table 1 is in its normalized form, while Table 2 has the Products and Quantity columns, which contain multiple values; this violates 1NF.

To normalize Table 2, we split the table into two separate tables: orders and order_items.
After 1NF we have tables 1 and 2 as follows:

First normal form
In 1NF, each field contains atomic values, and we've eliminated repeating groups of products within a single order.
Table 1 seems straightforward but has some problems:
Data redundancy: CustomerName, CustomerEmail is repeated for every order. Ideally, since there will be multiple entries, they can go into a table, say the customer information table, but we will be back to this.

Second Normal Form (2NF): Eliminate Partial Dependency A table is in 2NF when: It meets all the requirements of 1NF/Passed 1NF. All non-primary-key attributes are fully dependent on the primary key.

In order_items table, from the 1NF, the OrderID and ProductName together can form a composite key (data modeling technique that combines multiple columns to create a unique identifier for each record), but Quantity is already dependent on the combination of the two attributes. (OrderID and ProductName).
This means, however, that if we have data in the table that doesn't relate to the order, we would need to move it to a different table.
ProductPrice is dependent on ProductName, and not OrderID. Just like the price of products in a store does not determine orders made.
Therefore, to achieve 2NF, we need to separate product-related data from order-related data. We create a new products table.
By moving ProductPrice and ProductName to a new Products table, we ensure that every non-key attribute in the OrderItems table depends on the the composite key (OrderID, ProductID). This satisfies the goal of the second normal form.
After 2NF:

Table 2 in 2NF
Now, ProductPrice is stored in the products table, which keeps product data separate from order data, ensuring that each piece of data is only stored once.

Third Normal Form (3NF): Eliminate Transitive Dependency A table is in 3NF when: It is already in 2NF/Passed 2NF. All non-key attributes are dependent only on the primary key, and there are no transitive dependencies (i.e., non-primary-key attributes should not depend on other non-primary-key attributes).

Table 2 in 3NF
Suppose we have a CustomerAddress, for orders, it will be in the Customers Table and is dependent on CustomerName, not OrderID. This is the concept of transitive dependency, meaning the address is indirectly dependent on the order.
To achieve 3NF, we move the customer data into CustomersTable, we have an OrdersTable, ProductsTable, and OrderDetailsTable at this point.

Advantages of Normalization

- Data Integrity: Normalization ensures that the data is stored consistently. So, if a customer changes their name, you only need to update it in the Customers table and it reflects on all related tables.
- Reduction in Redundancy: By eliminating duplicate data, storage requirements are reduced. This is crucial in asystem where thousands of products, customers, and orders are stored.
- Efficient Queries: Normalization helps in writing efficient queries and data is stored logically in separate tables, reducing the chances of anomalies.

Disadvantages of Normalization

While normalization offers many advantages, it can also introduce some challenges:
Complex Querie

s: As data is spread across multiple tables, queries may become more complex and require more JOIN operations, potentially impacting performance.
Overhead: Managing relationships between normalized tables requires proper indexing and careful query optimization.

Denormalization: A Trade-Off for Performance

In certain or specific scenarios, especially in high-performance systems, some denormalization (reintroducing redundancy) may be necessary to optimize read performance. For example, storing the product name directly in the OrderDetails table can eliminate the need for a JOIN in read-heavy applications.

Conclusion

Normalization is an essential process in designing a relational database that is efficient, scalable, and maintainable. Normalization ensures that data such as customer details, products, and orders are stored in a way that minimizes redundancy, prevents anomalies, and maintains data integrity, create a well-structured database that supports the smooth operation.

However, while it is great to normalize, keep in mind the trade-off between normalization and performance, especially where necessary to optimize read-heavy applications.