Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I'm going to be talking to you about a way of organizing each and every piece of code that you have in such a way that makes it easier to reason about. This simple idea was introduced to me by a friend of mine here in Chattanooga. His name is Chris Keith Lee. We were hanging out at a Ruby meetup here in Chattanooga that I organized and Chris introduced me to this idea and I think it's really useful. I think it's going to be valuable to you. First I want to talk a little bit about some of the problems that this idea is going to solve. Have you ever spent time in your code trying to figure out trying to walk through each step and figure out what exactly is happening at a given step. I'm sure this is applicable in many different situations but trying to keep information in your mind about exactly what things are happening at that given point and time. That's a little bit hard to do because you are not the computer. In fact, you are simply writing the code that explains what you want the computer to do. Functional programming languages try to fix this problem by eliminating the idea of mutable state. The word mutable means that the state can change. Now imagine that you have, for example, a class level variable and that class level variable determines how a particular function runs. Maybe you have an if statement in that function that checks that class variable to determine what to do inside of that function. Of course I'm using the word function and method interchangeably here in this conversation but the idea is very simple. It's that there is something outside of that method that determines what is going to happen on the inside of that method. And as you're writing that method, if you have things outside of that method that determine what will happen on the inside of that method, then when you're reading that you have to consider those things without actually seeing them. In other words, the state is difficult to determine and the outcome of running a particular method becomes even more difficult to determine. This is perhaps one of the hardest parts of object oriented design and it's one of the things that you have to be aware of and there are ways around this problem. There are ways to subvert the hard parts in this problem. Have you ever found yourself writing a test that sets up a scenario? For example, creating a user and signing that user in and then visiting a page maybe using something like capybara. If you are using Rails and you sign that person in, you visit a page, you fell out of form and then you do all of these things to set up the state just to check a single method. Now let me be clear. Sometimes integration tests exactly like this are important and you should be creating those for the most critical paths in your application. But if you have to write a test, if you have to set up state in order to check a method, then there could be something wrong with the way your code is organized. In a minute, we're going to discuss two things that you can do to make your code a little bit easier to reason about and to get you away from relying on state, to get you away from this from holding everything in your head so that when you read your methods and when you are testing your methods, you don't rely so much on the external state and instead you rely on what exactly is happening in that method. Thanks so much to today's sponsor Code School. Code School is an online learning destination for existing and aspiring Developer That teaches through entertaining content. By pairing immersive video lessons with in-browser challenges, Code School has become the best place to learn new technologies from the comfort of your browser. Each course features a unique theme and storyline, so you feel like you're playing a game rather than sitting in a classroom. Whether you've been programming for decades or have only just begun, Code School offers something for everyone. Choose your learning experience from Code School's five main paths. JavaScript, Ruby, Git, HTML and CSS or iOS. Or you can take advantage of Code School's growing number of elective courses like Try-R and Chrome Dev Tools. Take your learning on the go directly from your iPhone or iPad from the free Code School iOS app. More than a million people around the world use Code School to improve their development skills and learn by doing. You can join them by visiting codeschool.com slash Developer Tea for more information and to start playing courses today. So we've been talking about mutable state and trying to get away from relying on mutable state to determine how a given method will run. I want to give you two basic refactoring tips, two basic ways of looking at your code from here on out, that will help you write methods in such a way that they don't rely as much on state, that the state is a little bit easier to reason about. This first idea comes directly from my conversation with Chris Keithley. Chris was talking to me about arranging data and performing different queries through rest type interfaces. And he mentioned that people have a hard time separating the arrangement of their code from the actions of their code. So this is my first tip for you today. Create the arrangement parts of your code and quarantine them away from the action parts of your code. So in practice, this for example, might look like you defining all of your variables and all of the pieces and parts that you're getting ready to use first. So avoid defining those variables interspersed with the actions that you're taking throughout the rest of the method. Another thing I've been practicing recently is substituting methods for queries. So instead of actually writing the query out inside of my method, I will offset that into another method. This allows the query to be easily reusable and it completely quarantines the arrangement, which in this case is the query, away from whatever actions you want to take on whatever that data is, whatever that query returns. And the second idea is to simply reduce the number of times that you use conditional statements. Now this is the hardest challenge of the two because it requires you to think in a new way. The truth of the matter is when you introduce a conditional into a method, that method is basically split into two different branches of a method when running if that conditional passes and when running if it doesn't. But if you begin to add nested conditionals, then you start creating a very complex situation where there are basically multiple methods nested inside of a singular method as a rule. I like to keep my conditional statements to a minimum, hopefully nested at most two conditionals, preferably only one conditional in a given method. Now there's a lot of techniques that will help you reduce the number of conditionals in your code. The scope of this episode is too small to cover them all, but for a good primer on this subject, I would recommend you check out Sandy Metz's talk from 2015 RailsConf, nothing is something. In this talk, she'll give you a little bit more intuition as to why conditional statements make code a little bit more difficult to reason about and how to avoid those conditional statements. Sandy specifically talks about how to deal with when an object is simply not present. In Ruby, we call this nil in JavaScript, this is null or perhaps undefined, but we experience this situation in pretty much every programming environment. The idea that a given reference is empty and how to deal with it. Go and check that talk out. It will be in the show notes. So I challenge you to these two things. Number one, start building your code so that the arrangement part of your code is quarantined away from the action part of your code. And secondly, reduce the number of conditional statements that ifs and the switches and the cases, reduce the number of those statements and instead focus on doing one thing at a time and doing it explicitly. I can almost guarantee that your code is going to be easier to read. Other people will find your code much easier to reason about and much easier to work on after you have finished working on it. Your tests are going to be much easier to write. You'll become a much better programmer and therefore you'll be happier. Now, I know this sounds very big. I know this sounds lofty and the goals seem really high, but the reality is these simple changes. These are the things that make your job easier, that make each and every day the moments of your life less frustrating, a little bit more zen-like if you want to use that term. A little bit easier to deal with the hard parts. So much for listening to today's episode of Developer Tea. I've got one more thing to talk about and that is learning. You guys know that it is so important to keep on learning as a developer each and every day. I've done so many episodes on how to become a better learner, but perhaps the best way to be a better learner and the best way to learn is to do to actually get on the ground and start coding. Code School is a way that you can start doing that. Code School is today's sponsor, of course. You can go and check it out at codeschool.com slash Developer Tea. That's a special link that lets them know that you're coming from Developer Tea. I would really appreciate if you use that link, which is in the show notes. Code School is a great option for you, whether you are at the beginning of your career, just learning how to do the very first basic hello world stuff, or if you're well into your career and you want to learn more about a given subject, they've got so many different courses, they've even got electives, so go check it out codeschool.com slash Developer Tea. Thank you again for listening to today's episode and until next time, enjoy your tea.