Clean, quality coding improves the quality of your codebase, reduces your software’s lifecycle costs, and makes you more in-demand and marketable. Here at Know the Code, we strongly advocate clean, quality principles.
This technical library provides you:
- Insights – quick tips, insights, and master tips
- Books – Tonya has books ready to teach you more about clean, quality coding
- Other Resources – other resources about clean, quality coding
What's the limit for inline comments, and how can you minimize them? Let's look at a bad and a good example of inline comments, and how they're chances to improve your code.
In today's quality code tip, you will learn about removing the HTML from your business logic and putting it into a view file. In programming, you want to separate out your code by its intent and purpose. Let's discuss the what, how, and why of view files. (Side note: I'm showing you the actual code on this website which is powered by Genesis.
Code Smell Alert: A common code pattern that I see is where the if/else logic and the if conditional is backwards. I call this the “if/else backwards code pattern.” This code pattern makes the code less readable, which decreases its quality. There are two clues to let you know that you have stumbled into this pattern: The if conditional is set off of a false state. Typically you’ll see a not operator (!) as your clue. The if logic is setting a default state. But that is the job of the else. Smelly Version This is the smelling code pattern: […]
When doing a conditional expression, it’s a smelly code pattern to then return true or false. Why? The conditional expression already returns a true or false state. Therefore, you do not need to be so verbose and hardcode a boolean return. Here is the smelly code pattern: Refactor this code down to one line to make it more readable. It’s less code too (skinny). Strive to reduce your code and make it more simple. If you see this pattern in your code, then refactor it. Remember, you want your code to be as skinny (as few lines) as possible.
Within a function, when you are done processing, i.e. the conditions are set, then return early. Don’t wait until the end of a function to return. Don’t wrap up your code in conditional expressions when you could have just returned early if the conditions were not met. Why? It makes your code hard to read. The guideline is this: When done, return. Otherwise, continue processing.
Let’s talk about naming of variables, functions, etc. in your code. In this video, you will learn some handy guidelines on naming by intent to let your code express what it’s doing, why it exists, how to use it, and what to expect from it. This tip is valid for all programming regardless of the language or technology.
You’re busy. You need easy wins, fast, and right now to make your code better. Bam, here are 7+ refactoring tweaks (+ 2 bonus ones) that you can do right now. Yup, quick, easy, actionable tweaks that saves you time and money.
The Little Green Book series are short, easy to read, and get right to the point. No fluff. Just quick, actionable solutions you can do right now…to increase your profits.
The best way to learn programming skills is by doing. This workbook gives you real code examples for you to fine-tune your refactoring skills. The solutions walk you through step-by-step to teach you how to identify, think about, and the go about refactoring code to be more readable, purposeful, reusable, lean, and clean.
Uncle Bob is a master craftsman and clean, quality coding advocates. He provides deep insights into the practice as well as methodologies through his articles, books, presentations, and programs.
Jeffrey Way of Laracasts provides you with a PHP-centric series on simple coding methodology.
Jeffrey Way of Laracasts provides you with a PHP-centric series on the SOLID principles, which is a driving force in what Tonya teaches you throughout all of her work.