Anyone can write code a computer can understand, but professional developers write code *humans* can understand. Clean code is a reader-focused development style that produces software that's easy to write, read and maintain.
Are you a technical debt generator? Do your co-workers cringe at the thought of having to work with your code? Clean code is the art of writing code humans can understand. Elevate your professionalism and increase your code quality by writing with the reader in mind! We'll walk through three core clean coding practices: 1) Select the right tool for the job. 2) Optimize the signal to noise ratio. 3) Create self-documenting logic. These practices are the foundation for a professional development career and provide developers a clear vocabulary for evaluating code quality.
Naming Hi I'm Cory House and this is Clean Code: Writing Code for Humans. In this module we're going to discuss Naming and why it matters. So, what's in a name? Well, we're about to find out. Here's our plan. We're going to discuss why Naming is so critical and learn some principles for selecting good Class names and some names to avoid. We'll learn how to avoid surprising people with nasty function side-effects and we'll wrap up with some principles for selecting good variable names. So, let's get started.
Functions Hi, I'm Cory House and in this module on Clean Code we're going to discuss Functions. We're going to learn how to create Functions that have a high signal to noise ratio for easy readability. We'll learn when creating a Function makes sense. And we'll discuss techniques to maintain simplicity in our code. We'll also learn some code smells to avoid and refactoring techniques for eliminating these issues all together. And finally, we'll wrap up by discussing error handling techniques. Now, before we get started a quick piece of business. Throughout this module you'll hear me use the terms Function and Method interchangeably. Understand that both are simply pieces of code that are called by name. The core difference is Methods are associated with an object. So, if you're not into object oriented programming don't worry. The term Method might sound foreign to you, but it's really the same thing for the purposes of this course. The two terms are interchangeable. The principles we'll be discussing apply equally to Methods and Functions. So, let's get rolling.
Classes This is Clean Code: Writing Code for Humans. I'm Cory House and this module is all about Classes. Now, this course is not specifically focused on Object Oriented Design. That's a large topic all by itself and there's already a great course available on Pluralsight on the SOLID Principles of Object Oriented Design by Steve Smith. Steve also worked with a number of other authors to create an excellent comprehensive course on Design Patterns. These are great followup resources for this course. That said, if you're working in Object Oriented Language well-structured Classes have a huge impact on maintainability and clarity of intent. So, this module covers some simple principles for designing and formatting Classes with the reader in mind. In this module we'll discuss when creating a Class makes sense, the importance of designing cohesive Classes, techniques for organizing the logic and flow of your Classes methods with the reader in mind, we'll learn to watch out for Primitive Obsession in our code, and we'll finish up by discussing the Outline Rule, which will help our readers speed read through our Classes and quickly understand our logic at the desired level of detail. So, let's dive in.
Comments Hi, I'm Cory House. In this module we'll be discussing the role Comments play in writing Clean Code. So, when I ask interviewees what Clean Code is to them they almost always mention Comments. And Comments indeed have their place. But, heres the thing. Overreliance on Comments is a Code Smell. And if this is all you can say about the topic of Clean Code that's not a great sign. Comments should only be chosen as a solution after a consideration of the alternatives. Like any other data structure there should be a clear reason to justify their existence. Comments are either Signal or Noise. So, let's walk through some examples. There's no shortage of opinion on the topic of Comments. It sure gets these girls fired up. Now, Sally has some good points. Comments are sometimes not kept up to date and they can be used to explain confusing code that could simply be refactored in a cleaner manner. But, Julie has an important point too. Many developers think their code is clean enough that it doesn't need comments, but as we've seen throughout the course, clearly conveying intent is not easy. So, you're probably looking for a definitive answer to the bottom line question. Are comments great, or a code smell? Well, I'm going to answer that definitively. Yes. Yes they are. How's that for a programmer answer? It returns true. As we'll see Comments are both.
Stay Clean Hi, I'm Cory House and in this final module of Clean Code: Writing Code for Humans we're going to discuss Getting and Staying Clean. We'll review some simple guidelines for when to refactor existing code using Clean Code Principles, as well as techniques for keeping our code clean. Once you've started enjoying the benefits of Clean Code Principles in the code that you write you'll be tempted to use these same techniques to refactor existing code. But, I like to remember the principle of if it isn't broke don't fix it. There's nothing wrong with improving your code base, but before you do so remember three simple rules. If you're refactoring code it should be code you're currently working with. Refactoring for future readers is of questionable values since it means your means investing time now for readers that may not materialize in the future. If code is hard to read, but exists in a system that's been chugging along reliably for years don't risk changing it merely in a desire for cleanliness. Refactoring is useful when you find the code difficult to comprehend or change. I emphasize the word you here because this is truly subjective. If you're fixing a simple bug and find the code clear enough, fix the bug and move on. Excessive refactoring of old code is of questionable value when the size of your change is small. Generally, the size of your refactoring should be in line with the size of the code change that you are making. If you need to make a simple one line change, refactoring multiple methods is likely excessive. Finally, before making any changes be sure you have sufficient test coverage to assure your changes don't introduce regressions in the code.