Classes

Classes are one of the core building blocks of OOP. Classes are containers that store information. They have attributes, which are often variables that store data. They also have functions (sometimes called subroutines or methods), which perform a specific task. Classes are like a recipe. They are a set of instructions to complete a specific task. For a cake recipe, the attributes could be the quantity of each ingredient or the total baking time. The functions could be helpful utilities such as mixing or baking.

Classes are a template (the recipe), but they don’t do anything on their own. For a class to be useful, it needs to be instantiated. This creates an object based on the template. Objects that get instantiated from a class are instances. They are individual instances of a class.

For the cake recipe, the objects are the finished cakes. This could be a blueberry cake or a chocolate cake. Each cake is its own entity (object), but both are based on the original recipe (class). Both of these cakes followed the instructions in the recipe but turned out differently. These objects started in the same class, but are not tied to each other at all. You can cook them independently, change the ingredients or the quantity, or delete one or both cakes – either by eating them or throwing them in the bin!

Everything in the core library for a programming language is a class. Even if you’ve never written a class before, you’ve used them. In Python, the for loop is its own class, as is the print function, or the string type.

Inheritance

Inheritance is a way of creating a new type of class based on some other class. Looking at the previous cake example, you have a cake recipe class. This is good for making cakes, but what if you wanted to make muffins? Muffins are a type of cake, but does the cake class need muffin-specific tooling? If it’s all clogged up with functions and attributes for all the different types of cakes, it may become large and cumbersome.

By creating a new class that inherits the parent class, your new class gains access to all the attributes and functions in the parent but can add extra attributes and functions. This new class that inherits from some other class is a subclass, while the parent is a superclass. If you subclass the cake recipe as a muffin recipe, you can still mix and bake the muffin objects, only now you may be able to pour the muffins into muffin tins, distribute many small muffins, or anything else you add to your muffin recipe. Subclassing/inheritance is the same as photocopying your recipe and writing a note on the bottom!

Encapsulation

Public members are accessible by anyone and anything. As the name implies, there is no restriction on these. Instantiated objects can all freely access this data. For the cake recipe, this could be bake or mix functions, or this could be the total baking time.

Private members are only accessible by code inside the class. The recipe class can change these, but any objects created from the class cannot even see these members. This is useful for code that’s only used internally. For your cake class, the baking method may be accessible to everyone, but what if it stores an internal baking temperature? If other people can access and change this value, the cake may burn. Making this private means only you (or other developers working on the class itself) can work with this.

Finally, there are protected members. This is like private, in that only members of the class can access this data, but is extended to any subclasses. If you create a protected member, the main class can access it, and so can any subclasses (such as muffins). Objects instantiated from the cake class cannot see or access this.

Many languages use tools such as getters and setters. These are often simple public functions that regulate access to private members. This is a good practice. Going back to the oven temperature example, it may be useful to let objects change the temperature, but suppose every time the temperature changes, you need to adjust the cooking time. If objects have access to the temperature, they could change it without adjusting the cooking time. They may not even know the cooking time should change. By using a setter, you can ensure the cooking time gets readjusted anytime the temperature changes. Besides this, you can change how data gets stored in your class, and any objects using the getter or setter do not need to change. This makes your code less fragile and easier to change in the future. This is encapsulation, and it’s a very important aspect of OOP. Only you, the developer, get to decide the rules and regulations around your code.

Unfortunately, Python does not have access modifiers. This can make Python code challenging to work with at times. While there are some pseudo-workarounds and Python best practices you’ll see in the project code, most of these revolve around trust. There’s nothing stopping you from accessing private data in classes, but don’t expect any help if things start going wrong. For the reasons mentioned earlier – sometimes data needs changing in a specific way, or other attributes calculated at the same time. For small projects or instances where you are the sole developer on a code base, you’ll often have enough working knowledge to know where potential hazards reside.

There are other access modifiers, but these vary between languages and are often an amalgamation of the main three.

The default method type varies per language, as does the need to specify one at all. In Python, instance methods are the default modifier, but in Java, it’s common to use static methods.

Static methods do not need access to any other class information. They don’t need specific object data such as ingredients or cooking time. Everything these need to run is self-contained in the function. A good example of this is a multiplication function. You give it two numbers, and it returns the product. This is what happens in any programming language when you use the asterisk sign. The reason you don’t need brackets or to instantiate the function is because special math symbols are designed for use as we’ve come to expect, but the language itself still stores this as a function.

Instance methods have full access to everything in the class. These get tied to the object itself. If your cake recipe has an instance method to get the weight of the ingredients, then this will change for every object. A cake may need 10 ounces of flour, whereas muffins may need 11 ounces. Instance methods can call both static methods and class methods, and each method is only aware of the data for that object.

Class methods can only call static methods in the class. They cannot access object-specific data, but they are not stand-alone functions like static methods. These are useful when you need to access other class utility functions, but don’t need specific data every time they run. If you don’t have any static methods, you won’t often need a class method. Only once you have static methods will you need to even consider a class method, and even then you’ll only need it if you want to access other static methods.

Polymorphism

Compile-time polymorphism (sometimes called overloading) is only possible with statically typed languages. This can be very fast as the compiler does all the work. The most common compile-time polymorphism technique is function overloading.

Function overloading lets you use different data types or even parameters in a function. Suppose you have a function called bake. It takes one parameter, an integer called duration. Without function overloading, you couldn’t create another function in the same class with the same name. By overloading this function, you can. You can create functions with different data types, or a different number of parameters. For example, you could change the bake function to take a single string called duration. You could also change it to accept two integers, duration, and temperature. When you compile your code, the compiler will choose which function to use, based on the supplied arguments.

You can also change the return type, but you can’t only change this, you’ll need to change the signature as well. The code for these functions can be different, or one can change the data and call the other one. By overloading functions, you can make your code flexible, and able to handle a variety of different parameters and data types.

Operator overloading is similar, but it lets you define custom functions to extend the built-in operators. A good example of this is the addition symbol. This works fine for integers but will crash if you try to add strings or custom classes. By overloading this operator, you can create custom functions to add your own data types or classes.

Dynamic method dispatching resolves references when the code gets run, instead of at compile time. This approach is more flexible than compile-time polymorphism and is useful when it’s not possible for the compiler to figure out the function you need. The outcome is the same as compile-time function overloading. It may not be possible for the compiler to decide what to do for many reasons. Perhaps one or both of your overloaded functions extend the other, or perhaps you base the function on user input, which is not known at compile time.

Design Patterns

Design patterns are blueprints in the sense that they describe how to solve a problem. They are not quite the same as classes (which are also blueprints). Design patterns give you a handy way to describe a solution. When you bake cookies, you don’t say to your friends “hey, want some round baked goods, made with chocolate chips and dough?”, you use their name – cookies! Design patterns can help you to communicate with your team. Design patterns consist of a name, a problem, a solution (ideally language agnostic), and an outline of the possible side effects of this solution (if any).

Creating a new design pattern is possible, but improbable. Design patterns arose out of engineers designing similar solutions to problems, so unless you can get your code written into thousands of different code bases, and set the world alight with your unique solution, it probably won’t become a new pattern.

Design patterns evolved in the late 1970s, but they rose to popularity after the famous gang of four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) held a workshop in 1991 and then published their book Design Patterns: Elements of Reusable Object-Oriented Software. Their book documents 23 different design patterns. Some common patterns are as follows:

The Adapter Pattern acts as an interface between incompatible objects. An example of this would be calling the baking method on a roast chicken. It still needs baking, but chickens are not part of the cake class. By writing an adapter to interface the two, you can make it work.

The Decorator Pattern is one of the most well-used patterns in Python. This lets you extend classes through subclassing but dynamically at runtime. This pattern is very powerful, and happens per object, independently of any other class instances.

The Facade Pattern provides an interface to a class or piece of code. If you need to call ten different functions in a specific order to use your class, a facade pattern can wrap these into one simple-to-use function, which performs all the work in the correct order.

The Factory Pattern delegates the creation of objects to a centralized entity. This is useful for letting subclasses define which superclass to use, without getting bogged down in the details.

This is only a small fraction of all the possible design patterns. The 23 documented patterns in the GoF’s book have achieved almost legendary status – and for good reason. Next time you’re looking to solve a software problem, check that a design pattern doesn’t already exist.

SOLID Principles

SOLID is a mnemonic for five object-oriented design principles introduced by Robert C. Martin in his 2000 paper titled “Design Principles and Design Patterns.” These principles exist to make software easier to develop, easier to fix, and easier to understand.

The single responsibility principle states that each individual component of a code base should have sole responsibility for one piece of functionality. The reason for this is to limit the work required to make a change. If you’re making doughnuts and decide to change the filling from jam to custard, you shouldn’t have to change how you mix the batter. If there is only one place in your code that handles a requirement, it becomes very easy to change this and the code. If one part of your code handles several different operations, or several different pieces of code involve the same operation, it becomes a confusing mess to change any code.

This doesn’t mean your code should be tiny and only perform one task. It’s fine to have different functions grouped together, but they should be loosely related. Code for icing cakes can all live together, and code to dust doughnuts with sugar can live here as well – both are a type of glazing. Code to fry doughnuts belongs somewhere else.

The open-closed principle is the idea that software components should be “open for extension, but closed for modification.” Through this, it should be possible to extend the functionality of a component without changing its original source code. In simpler terms, your code should need few changes to meet a new or recently changed requirement. This is often carried out through inheritance or polymorphism.

Say you have a function to calculate the surface area of a doughnut (very useful to know how much icing to make). This works very well, but it’s not very flexible. If you want to calculate the surface area of a cake or even a square cake, you need to change the code. By writing this function to calculate the surface area of any baked good, you can be confident your code can handle any future confectionery requirements. Don’t get too carried away though, as YAGNI.

YAGNI stands for you ain’t gonna need it. It’s a reminder to only put in place features you need right now, and not start coding things nobody has asked for. If nobody wants a feature, or you start coding features you think people will want, that’s a lot of wasted effort for little reward. With a new code base, startup company, or code following the open-closed principle, it can be a fine balancing act between flexible code and worthless features, but taking the time to think through your solution can make a big difference.

Liskov substitution suggests that subclasses should be direct substitutes for their superclasses. In other words, you should be able to swap a parent instance for a child class and nothing changes in the code. It’s fine for your subclasses to extend the behavior of their parents, but if a subclass is fundamentally different or incompatible with its parent, you should redesign your solution.

Here’s an example. Suppose you have a class for cakes. Your code follows the open-closed principle and allows for all kinds of extensions. This works great for a variety of cakes: cupcakes, muffins, Victoria sponges – yum. Then, along comes a pastry chef with some fresh doughnut batter. It’s possible to subclass the cake class as a doughnut, but doughnuts are usually fried, not baked. All the cake-specific functions and attributes don’t work on doughnuts.

You could create new functions to fry or override the bake function to perform frying duties on the subclass, but this starts to get confusing. Even with a highly modified doughnut subclass, anything or anyone using instances of these objects will get themselves into all kinds of trouble. Doughnuts need a deep fat fryer or at least a frying pan – will the pastry chef have one available if the function is called “bake,” and the documentation says it requires an oven?

By following the Liskov substitution principle, it should be very clear what your objects are, how they work, and the functionality they implement. It’s fine to extend classes, but drastically changing how they work, or implementing “quick fixes,” “hacks,” or other nasties is a bad idea.

Interface segregation states, “No client should be forced to depend on methods it does not use,” and is summarized as splitting large modules and classes into smaller and easier-to-use pieces. This applies to huge modules more than smaller projects, but it’s still worth considering.

Here’s an example. Your cake class wasn’t useful for all cases (such as doughnuts), so you modified it to become a generic confectionary class. This class can do everything – baking, frying, mixing, icing, and more. While it’s a good class, written using the other four SOLID principles, it’s massive. It’s thousands of lines long, and developers dread working on it. By moving pieces out into their own classes, you can reduce the size of this mega-class and make the code easier to understand, read, and use.

You could have individual classes for baking, frying, and icing. You could have a utility class for common functions. Now, the confectionary class implements the other classes through its own instances.

The final principle is dependency inversion. High-level modules should not depend on low-level modules. Both should talk to each other through abstractions. High-level modules should provide complex business logic and be easy to reuse and change. Low-level modules should provide operations such as network or disk access.

Without following this principle, tightly coupling business logic to a file handler means that changes to the file handler (such as using a different library or function) need changes to the business logic.

Here’s an example. Your high-level cake classes handle the production of cakes – mixing, baking, stirring, and so on. These classes shouldn’t care about how the oven produces the heat. They put cakes in, set the temperature, and then remove them after a set period of time. If the cake class had to call an oven function such as “heat up coil for 15 minutes,” then this is very tightly coupled. What if you get a new oven? What if it’s gas-fired, or charcoal? Suddenly the cake class needs updating to call the appropriate functions to light the gas or empty a new bag of charcoal. If these classes talk to each other through an abstraction, only one piece of code has to change.

This may seem complex, but by following the Liskov substitution and interface segregation principles, you almost get dependency inversion as a by-product.

1992 London Ambulance Service Computer-Aided Ambulance-Dispatch System

On 26th October 1992, the London Ambulance Service deployed a new computerized system to dispatch over 300 emergency ambulances to 7 million people living in a 600 square mile area of London. This was a brand-new computerized system designed to replace the fully manual process.

Within hours of launching, the system was unable to keep track of ambulances. As many as 46 people died because an ambulance did not arrive in time, never arrived at all, or in some cases, more than one arrived. For one patient, by the time the ambulance arrived they had already died, and been that way for quite some time.

The ambulance-dispatch system failed to function when given incomplete data about ambulance locations. As the system didn’t know where ambulances were, it attempted to reroute or dispatch vehicles currently in use.

This memory leak retained event information on the system even when it was no longer necessary. Over time (and compounded by the excessive call volume due to the early failures), the memory filled up, and the system failed.

By defensively programming this system from the beginning, some of these problems may have been avoided. While testing and deployment all work together for the benefit of the customer (and this project has far greater deep-rooted problems), by assuming the worst will happen and preparing your code to handle it, you can start to stem the flow of a problem before it even arises.

You’ve read how badly things can go wrong, but that can never happen right? Sitting at home coding your small little system can never kill anyone? Perhaps not, but you don’t know where your code will end up if you share it online, or what projects you might pull your code into in the future, because you have a working solution.

The final aspect of defensive programming is that of security. Secure programming is a subset of defensive programming. By writing your code to expect vulnerabilities, and never trusting anything or anyone, you’ll be in a much better place from a security perspective. The OWASP Top Ten Project is a curated list of the ten biggest security threats facing any application today. Security mitigations follow some of the advice already mentioned. Deny everything by default. Validate all input, and keep it simple. While this project has limited interaction with users and the outside world, it’s still vulnerable.

During development with your Raspberry Pi on the Internet, it’s common for automated systems to access (or attempt to access) your Pi in unexpected ways. Perhaps you have default passwords set or services enabled and running on default ports. If you take the pessimistic approach that everyone is out to hack you, and never assume anything will always be available, you’ll end up with a far better system, which provides the user (you!) with a very pleasant experience, even if the worst happens.

Therac-25 Radiation Therapy Machine

The Therac-25 was a software-controlled radiation therapy machine released in 1982. Through this machine, hospital operators treated cancer patients with radiation. Hospital machinists programmed the dosage, duration, and location of the beam, and the machine handled the rest. Between 1985 and 1987, the Therac-25 caused at least six accidents, with some patients receiving over 100 times the normal dosage of radiation. These patients either suffered serious injury or death. The US Food and Drug Administration (FDA) issued a mandatory recall on all Therac-25 machines due to their potential for serious harm.

This is an interesting and popular case study in computer science. Before looking at the root cause of the failures, it’s necessary to understand how the machine worked, and the history of its predecessors.

The Therac-25 was a two-in-one radiation therapy machine. It used magnets to deliver direct electron-beam therapy. This is used for treating cancer near to the surface of the skin. The other mode of radiation therapy was a megavolt X-ray. This delivered radiation doses 100 times higher than direct electron-beam therapy, and as a result, the beams had to pass through both a filter and a combiner to ensure precise and accurate delivery. These extra tools were not needed for the other beam, and due to its increased power, the megavolt X-ray was mainly used for deep-tissue treatment such as lung cancer.

In summary, the Therac-25 used two radiation beams: a low-power beam and a high-power beam, which needed filtering and focusing. It also had a patient light, used to help position the patient without delivering any radiation.

One of the major flaws in this machine was the ability to select and use the high-power mode without the necessary filter and focusing components in place. This happened due to a software bug caused by rapidly switching from the low-power to the high-power mode. This meant patients received a lethal dose of radiation in a large area due to the lack of filtering and focusing devices. Another flaw allowed the low-power electron beam to activate when in patient-light mode.

Previous models of the Therac used hardware to ensure that these conditions could never happen. The Therac-25 removed these to reduce the cost and used a software version, which failed.

From a testing perspective, you can write all the automated tests you like, and you won’t catch these issues. Many of these arose out of the reuse of a previous generation model. The developers assumed that because this machine has been running for a long time, it must be good and safe, and so they can rush out this upgraded model. This was not the case and the significant software upgrades necessitated significant new testing. Onto the testing failures:

There are so many problems with this machine that not all would have been solved by testing, yet it remains my opinion that good testing, defensive programming, and code audits would have saved the lives of everyone harmed by this machine. That said, the benefit of hindsight is a wonderful thing. After the incident investigation, International Electrotechnical Commission (IEC) 62304 was introduced to specify the design and testing required for medical devices.

As this example shows, any testing is better than no testing, and don’t make assumptions. Testers love testing edge cases but thinking about the possible ramifications of your code (especially code that can so easily injure or kill people) is a step in the right direction.

Now you know what can happen when testing fails, let’s look at how to avoid big problems such as these. It’s important to have a common understanding of the tools at your disposal. First, don’t think of yourself as a developer and someone else as a tester. Testing is the responsibility of everyone involved in developing software! Testing can be loosely split into three categories.

Functional testing aims to assess whether the software meets the predefined requirements or specifications. The first step is defining these specifications! When functional testing, systems should provide a fixed output with a fixed input. For example, with a calculator, feeding in “1 + 1” should output “2”.

Performance testing looks to assess the speed, responsiveness, and stability of a system. If you’re building the next Facebook, then you’ll want to know the system can handle more than a handful of users at the same time. When you press a button, how long does it take before you get a response? Your acceptance criteria may vary depending on the project and the deployment. If you’re writing a script for your own use, then you may have simpler requirements than a system processing thousands of transactions per second.

Finally, there is regression testing. Regression testing helps ensure that new features and changes have not broken existing features. If you’re working on a legacy system, a big project, or generally playing “whack a mole” with a spaghetti code base, then regression testing couldn’t be more important.

As for specific ways of testing, the following snippets cover some of the over 150 different testing techniques, skills, tools, and processes available to modern-day developers.

Unit testing exists to test a specific piece of code in isolation. By writing small, single responsibility functions, you can unit test that a function performs as intended. Say you have a function to add two numbers together. If you input 5 and 6, you should get 11. You can test edge cases for this. Should it throw an exception if you pass a string? What about fractions, or will it only work with whole numbers? Unit testing should give you confidence that each piece of code is working as designed. Returning to the tasty cakes analogy, unit tests could cover breaking the eggs, measuring the flour, and setting the oven temperature. Unit tests wouldn’t usually cover if the cake tastes nice or even looks like a cake after following all the steps.

Integration testing tests how individual components interact with each other, and with the whole system. It can only happen when two or more distinct parts of a system are ready. So often it happens right at the end of development after everything has been produced (if it happens at all). While this is better than no integration testing, the sooner you can run integration tests, the sooner you can get feedback on if your solution works or not. By shortening this feedback loop, you can get into a position where customers get new features faster, and with fewer defects.

If unit tests test you can break the eggs, integration tests verify that the eggs get mixed correctly with the flour, the cake starts to rise in the oven, and the icing sticks to the top of the finished cake.

System testing helps developers and testers gain confidence in the nearly finished product. This is often performed by independent testers – people who were not involved with the development of the system. Integration testing happens on two or more different components, whereas system testing happens on the whole system. System testing could test that the cake looks like a cake, it takes nice, is chocolate, and has icing and sprinkles. This involves evaluating the system against the supplied requirements.

Acceptance testing exists to ensure the system meets the business or client requirements, and if it’s ready to release, or needs more work. The business may decide that the system is brilliant, but it’s missing this amazing feature that it must have before it is ready to release to the wild. For a birthday cake, no matter how amazing it tastes and looks, it must have candles. Cupcakes should be small and there should be many of them. Acceptance testing happens toward the end of the process, but it doesn’t have to. By getting feedback on small individual features as they are ready, you can assess their suitability.

Internal acceptance testing (or alpha testing) happens internally with people not involved in the development process. This could be customer support teams or sales teams. User acceptance testing (UAT) or beta testing involves getting the system into customers’ hands. By getting real customers to use the system, you gain new and exciting insights. Is it really what they want, or does it need a little more work?

Load testing ensures the performance of a system is adequate when running under its anticipated load. It can be difficult to predict the demand for your product if it’s a simple app that solves a simple problem. By load testing the system to its breaking point, you can figure out its maximum load, and extrapolate that to give you a rough idea of future scaling requirements.

Back to cakes, load testing cakes is quite simple. You hand them all out and count how many people get one. If you’re a good baker, you may want to factor in the fact some people will eat more than one muffin or a slice of cake.

Load testing sometimes emulates the load from a known or expected quantity of users. It can also serve to stress test the entire architecture to find its breaking point. Tools such as JMeter or Gatling can spin up users to an almost unlimited number, depending on your requirements.

Black-box testing happens from a user’s point of view. The tester has no knowledge of how the system works or if you need to perform any special steps to get a feature to work. This testing does not prod the delicate internal organs of your code. By using testers with no knowledge of the code, black-box testing avoids the developer bias and tunnel vision sometimes present when working on a big project. Black-box testing can happen for integration, system, and acceptance testing.

White-box testing involves studying the code in question and determining both the valid and invalid operations expected of it. By assessing the outcomes of both these types of operations, white-box testing is excellent at determining if a system is working, and which edge cases it is unable to handle. White-box testing can happen with unit, integration, and system testing.

Mocking works alongside unit tests. Its main purpose is to imitate a different part of the system or an external resource which is not under test at that moment in time. Suppose you make a call to an external API, but every time you do so it costs you $1. Making this call in your unit tests could end up costing you a lot of money, so how can you run unit tests? By imitating this external API call, you can replicate the result without spending a cent.

Test-Driven Development (TDD)

Test-driven development operates around a very short feedback cycle. It starts by writing a very simple test. You then write just enough code to pass the test. After the test passes, it’s time to refactor the test to include a basic requirement. Now back to the code to pass the test, this process repeats several times until all the requirements are met.

By writing the tests first, you’re forced to consider how your code will work, rather than sitting down and writing whatever code comes to mind. If your test only includes one basic requirement, you’re less likely to develop features you think will be needed in the future, which wastes time and resources. This all comes back to the SOLID principles discussed earlier in this chapter.

There are many benefits to developing a module with test-driven development. The biggest of which is a complete set of (unit) tests! At any point in the future, you can come back and rework, refactor, implement new features, or otherwise change your code, safe in the knowledge that your unit tests cover all the conditions required to continue working. Naturally, there may be new requirements and changes needed to the unit tests themselves, but generally, you should avoid changing both the test and the code at the same time, as you may not be able to trust that either component is working.

Some developers slide back into old habits after trying test-driven development – either through familiarity or because it involves too much effort. Some teams only work in a TDD way, and others may develop a hybrid system, encompassing a little TDD. Providing you have a good amount of unit test coverage encompassing many of the possible edge cases and error conditions, it probably doesn’t matter too much how you got there.

Rubber Duck Debugging

Rubber duck debugging isn’t as daft as it sounds – and it doesn’t have to be a rubber duck. By explaining your code line by line to someone else, the problem will often materialize. The act of revisiting every line of code is often enough to cause the problem to leap out at you.

Why the rubber duck? While other developers work equally as well, it disturbs the work they were doing. If you explain the code to an inanimate object (which has no dreams and visions of its own), then you can fix the problem without disturbing a teammate.

Rubber ducks have become an iconic symbol in developer pop culture, thanks in part to the book The Pragmatic Programmer (Andrew Hunt and David Thomas). Anything will do, as stepping through the code itself is the solution . The ducks aren’t magic.

Logging

Logging is the process of outputting descriptive statements at key points in the code. Seeing exactly where the code is or what happened at any moment in time is a crucial clue in the riddle of the code.

Through these logs, you can see what the code is doing, and trace each log back to the line of code executed.

Logs are often implemented through a log handler. These log handlers often come included in many frameworks. They let you log data through logger levels. Useful debugging information could go to a debug level, while serious crashes could go to the error level. It’s possible to set the logging level so you only see the errors, for example. This keeps your production logs tidy, yet still lets you enable more verbose logs as and when required. These log handlers often output the file, date, time, or any other useful information – you can configure the format.

Breakpoints

“You know nothing. In fact, you know less than nothing. If you knew that you knew nothing, then that would be something, but you don’t.” – Ben Harp, Point Break (1991)

Breakpoints let you stop the flow of your code. They pause execution and allow you to inspect all your variables. You can see the exact state and conditions your code is in. You can resume execution and see where the code goes next. Breakpoints are useful when debugging software. They don’t make any assumptions but may highlight some odd behavior that you can fix. By inspecting the code while it is executing, you can spot anything which is not the expected behavior.

As this quote highlights, you don’t know anything about your code until it runs. You may think you know how it works, and for most of the code you may be correct. When things go wrong, however, the best way to figure out the problem is by halting the code with a breakpoint.

Programming languages such as Python come with support for debugging and breakpoints. Your tooling needs configuring (often performed through your IDE), but once configured, it’s often as simple as pressing “debug” instead of “run.” Breakpoints specify the line of code to pause at. Once the software reaches that line, it pauses execution instead of continuing. You can add or remove breakpoints, continue execution, or cancel the debugging altogether.