Side effects are any observable change to the state of an object. Some people might qualify this by saying that side effects are implicit or unintended changes to state.
Mutator methods, or setters, which are designed to change the state of an object, should have side effects. Accessor methods, or getters, should not have side effects. Other methods should generally try to avoid changing state beyond what is necessary for the intended task.
Why are these guidelines best practices though? What makes side effects so bad? Students have asked me this question many times, and I’ve worked with many experienced programmers who don’t seem to understand why minimizing side effects is a good goal.
For example, I recently commented out a block of my peer’s code because it had detrimental side effects. The code was intended to add color highlighting to log entries to make his debugging easier. The problem with the code was that the syntax highlighting xml was leaking into our save files. He was applying the highlight to a key, then using that key both in the log and in the save file. Worse still, he wrote this code so that it only occurred on some platforms. When I was debugging a cross platform feature, I got very unpredictable behavior and ultimately traced it back to this block.
This is an example where code was intended for one purpose, but it also did something else. That something else is the side effect, and you can see how it caused problems for other developers. Since his change was undocumented and uncommented, I spent hours tracking it down. As a team, we lost significant productivity due to a side effect.
Side effects are bad because they make a code base less agile. Side effects cause bugs that are difficult to find, and lead to code that is more difficult to maintain.
Before I continue, let me be clear that all code style guidelines should be broken sometimes. For each situation, a guideline or design pattern may be better or worse, and I recognize that we are always working in shades of gray.
Generally, a block of code should be written for one purpose. If it is a method, then it should do one thing. If another thing needs to be done with an object, then that should be encapsulated in another method.
Here’s a hypothetical example that I’ve seen played out hundreds of times in my career.
A class needs to do task X. A programmer may write a method to do task X, but he accidentally includes logic that also does task Y. Later, he may see that he needs to do task Y all alone. So he writes a method to do task Y. That’s where the problem is compounded.
Later still, the definition of task Y changes. So another programmer has to rewrite task Y. He goes to the class, changes the method for task Y alone, does a few quick tests, and proceeds on his merry way.
Then mysterious bugs start occurring. QA can’t really track them down to one thing because they only occur sporadically after task Y. Finally, it takes many man-hours to remove task Y from the method for task X.
In this example, the side effect led to code duplication, which led to trouble when updating the code, which led to bugs that cost many hours to track down. The fewer side effects you introduce, the easier your code will be to maintain.
These two examples show how side effects can derail development and why they are so inimical. We all write code with side effect occasionally, but it’s our job to figure out how to do it in a way that doesn’t make the code more difficult to maintain.
Made using the Circular Sound App on the Google Play Store.
I created this piece with my Swarm Sound app, which is available on the Google Play store.
I’ve just finished work on a new musical instrument for Android devices. It’s called Circular Sound, and it’s aimed at people who like noise.
Circular Sound is similar to my other recent mobile instruments in that it combines a sampler with custom digital signal processing, and a unique interface. Sounds can be loaded from a configurable directory on the device, or you can play around with the default sounds, which are from freesound.org. Then they are loaded into spheres that are arranged in a circle on the left half of the screen. The left half of the screen is the source audio mixer, while the right half is used to control effects. The effects include waveshaping, granulation, delay, and modulation.
The goal of Circular Sound is to give a simple access point into generating various types of noise that is related in some way to the source sounds provided by the user.
Download it for free on Google Play and shoot me a comment to let me know if you make something cool with it!
I’ve spent the last several months working on a new book about programming synthesizers in Java. The book is finally finished and available to read on my site, and available for purchase in Kindle format on Amazon.com.
The book has two parts. The first part is 11 chapters long and introduces basic synthesis concepts like unit generators, envelopes, filters, additive synthesis, and modulation synthesis. The later chapters deal with slightly more complex issues around granular synthesis and rendering output. The second part of the book is a list of demo projects where I show readers how to build some of the features found in popular hardware synthesizers, such as an arpeggiator.
To some degree this book is a follow up to my previous book, Sonifying Processing: The Beads Tutorial, but it differs in several key ways. First, the new book is written in Java, not Processing, so it is aimed at a slightly more technical audience. But I’ve also included more introductory material, so there is material to help along newbies as well. Second, the book is more focused on building popular music synthesizers. There is a chapter about connecting up a MIDI keyboard, and the examples focus on instrumental, tonal sounds, rather than abstract sound mangling. Third, this book is focused more on synthesis techniques than on the Beads Library in general. So each chapter teaches one specific concept related to general purpose sound synthesis techniques.
These images were not created while I was drinking. Rather, they were created using an algorithm that combines several random walks, which are also known as drunk walks.
In the past few days I’ve completed several programs that compose rather nice notated music using cellular automata. Yesterday I posted seven solos generated by cellular automata. Today I am following up with two duets. Like the solos, these pieces were generated using elementary cellular automata.
All of these pieces look rather naked. In the past I’ve added tempo, dynamics, and articulations to algorithmic pieces where the computer only generated pitches and durations. Lately I feel like it’s best to present the performer with exactly what was generated, and leave the rest up to the performer. So these pieces are a bit more like sketches, in the sense that the performer will fill out some of the details.
I’ve collected several pieces composed using cellular automata into one package.
This collection of seven solos for any instrument was created by computer programs that simulate cellular automata. A cellular automaton is a mathematical system containing many cellular units that change over time according to a predetermined rule set. The most famous cellular automaton is Conway’s Game of Life. Cellular automata such as Conway’s Game of Life and the ones used to compose these pieces are capable of generating complex patterns from a very small set of rules. These solos were created by mapping elementary cellular automata to music data. One automaton was mapped to pitch data and a second automaton was mapped to rhythm data. A unique rule set was crafted to generate unique patterns for each piece.
This is my synthesizer arrangement of Debussy’s Prelude to the Afternoon of a Faun.
Isao Tomita did version with actual analog synthesizers in the 1970s.
Massive is a Native Instruments synthesizer that is strongly associated with dubstep, and with modern electronica in general. As a commercial product, it is primarily designed for use as a musical instrument within the setting of pitched, tonal music. Still, I’ve been curious about how far I can push Massive to create strange, other-worldly synth sounds. For the past few weeks I’ve been creating Massive presets that take Massive out of its usual setting, and apply it to the task of abstract noise and soundscape generation. The bundle is called Strange Transmissions, and it shows the versatility of the Massive synthesizer.