Freek.dev

? Don't use magic numbers when defining any TTL (like cache or cookies) in PHP. Use human-readable intervals instead. pic.twitter.com/ZC6S6BVMUi

— Marcel Pociot ? (@marcelpociot) September 23, 2019

Read more [twitter.com]

? In many cases avoiding `else` and using early returns will greatly improve readability of your code.

I wish somebody would have told me this sooner in my career.

Contrived example in the image. Real world example: https://t.co/oOsSGAJLZm#bestpractices pic.twitter.com/YgqB0kMIpg

— Freek Van der Herten (@freekmurze) 17 september 2019

Read more [twitter.com]

In an older but still relevant post, Jeff Atwood shares why you shouldn't use boolean parameters and how this translation to UI.

Read more [blog.codinghorror.com]

Matthew Rocklin reminds us that sometimes you shouldn't extract code.

However, there is also a cost to this behavior. When a new reader encounters this code, they need to jump between many function definitions in many files. This non-linear reading process requires more mental focus than reading linear code.

Read more [matthewrocklin.com]

Emily Shaffer makes the case for commenting regular expressions.

It’s probably not a good idea to encourage your coworkers to think critically about what life would be like if you got hit by a bus, but the good news is that you can simultaneously document your regular expression and teach your coworkers some regex basics, if you comment them carefully!

Read more [nasamuffin.github.io]

? Reviewing your code for symmetry is a great way to improve readability.

To get started, check for paired naming, consistent tone, and relative complexity. From there any remaining asymmetric bits will be easy to spot.

Here's a before and after snippet from the @OhDearApp. ? pic.twitter.com/KAhzYBxzSd

— Jason McCreary (@gonedark) September 17, 2018

Read more [twitter.com]

Whenever you find yourself using || or && in an if statement, consider extracting the conditions of that if statement to a dedicated method with early returns. It's more readable and it makes debugging much easier.

Example: https://t.co/hUcq29uP54

— Freek Van der Herten (@freekmurze) September 12, 2018

Read more [twitter.com]

I often use Eloquent's `query` just to have the code better aligned#visualdebtisreal pic.twitter.com/0JWrzx6wEN

— Freek Van der Herten (@freekmurze) 2 juli 2018

Read more [twitter.com]

Michael D. Hill posted a great new video on his blog where he makes the case for optimizing for scannability.

As programmers trying to ship more value faster, we want to optimize first around the part of the work that we spend the most time on, and that is scanning code– formulating little, tiny questions and flipping through the code looking for the answers. We optimize for scanning by focusing our attention on sizing, grouping, and, above all else, naming.

http://geepawhill.org/optimizing-a-program-and-programming/

Read more

My colleague Brent has some good thoughts on where to place curly brackets.

Dedicating a whole blogpost to curly brackets might seem like overkill but I believe it's worth thinking about them. Not just because of one curly bracket, but because there's a bigger message in all this. Thinking about how we read and write code not only improves the quality of that code, it also increases our own and others ease of mind when working with it. It can improve the fluency of your work and free your mind to think about real important stuff.

https://www.stitcher.io/blog/where-a-curly-bracket-belongs

Read more

In an older, but still relevant, post on Medium John Saito demonstrates the effect of different capitalizations.

Can you spot the differences with the messages above? The left side has a few more capital letters than the right side. Big O, little o. Who cares, right?

Well, if you write for an app or website, you should care. A little thing like capitalization can actually be a big deal. Capitalization affects readability, comprehension, and usability. It even impacts how people view your brand.

We’ll get to the juicy stuff in a bit, but first, let’s start with a little more background about capitalization.

https://medium.com/@jsaito/making-a-case-for-letter-case-19d09f653c98

Read more

???? Symmetry is a hallmark of clean code. Symmetrical code is not only easy to read, but also predictable. Here are a few areas to check your code for symmetry. pic.twitter.com/jGVdR0aek7

— Jason McCreary (@gonedark) November 30, 2017

Read more [twitter.com]

???? Pushing yourself to remove comments is one of the best drivers towards clean code. Here's a few tips on how to spot and replace comments that may be unnecessary… pic.twitter.com/STIK6AIKXt

— Jason McCreary (@gonedark) 16 november 2017

Read more [twitter.com]

Jason McCreary, creator of Laravel Shift, wrote a down a two part series on how to write cleaner code.

To measure our change, we should ask: Did we improve readability?

Admittedly a bit subjective, but you push yourself to stay objective. I've been pair programming for the last two years. Developers tend to agree on fundamental readability. Where we differ at the edges. These nuances can lead to some pretty great discussion.

...

The answer to did we improve code readability may vary from developer to developer and project to project. But always ask the question…

https://dev.to/gonedark/writing-clean-code https://dev.to/gonedark/writing-clean-code-part-2-9fn

Read more

Caleb Porzio gives some good advice on how to make code more readable in this talk given at Erie Day of Code 2017.

Read more

At last years Istanbul Tech Talks conference Kevelin Henney gave this great talk on how to improve the readability of your code.

Here are the slides of this talk.

Read more

Grégoire Paris wrote down his opinion on why he dislikes Yoda conditions.

So how do Yoda conditions work? Well it is basically a knee-jerk reaction you have to develop: whenever you write a condition, put the operand that cannot be assigned on the left. This should give you an error message if you make an assignment when you actually meant to make a comparison.

https://dev.to/greg0ire/why-using-yoda-conditions-you-should-probably-not

Personally, I'm not a big fan of Yoda conditions either. My feeling is the the cost of decreased readability is just too high for the small value that Yoda conditions bring to the table.

Read more

Brent Roose wrote down his thoughts around how things like fonts, spacing, docblock, ... can influence the cognitive load of a programmer.

As a professional programmer, I'm reading and writing code on a daily basis. I'm working on new projects, doing code reviews, working with legacy code, learning documentation etc. Based on my own experience and that of colleagues, being a programmer often involves a lot more reading than actually writing code. Whether it's your own code or that of others, when you open a file, you have to take it all in. You need to wrap your head around what's going on, before you're able to write your code. Doing this day by day, it's important to find ways to make this process easy. To try and reduce this cognitive load as much as possible. Streamlining the way you take in code, will allow you to not only work faster and better; but also improve your mental state and mood.

https://www.stitcher.io/blog/a-programmers-cognitive-load

Visual debt is real.

Read more

Mattieu Napoli shows how you can use non breaking spaces to make long test function names more readable.

Yes. This article is about using non-breakable spaces to name tests. And the fact that it’s awesome. And why you should use them too.

public function test a user can add a product to a wishlist() { // ... }

The code above is valid PHP code and works. Non-breaking spaces (aka   in HTML) look like spaces in editors but are actually interpreted like any other character by PHP.

http://mnapoli.fr/using-non-breakable-spaces-in-test-method-names/

It's cool that it works, but I'm not really a fan of this. I very much prefer how test runners like jest go about this by passing the name of the test to a function so you can use spaces.

Read more