Freek.dev

In a new post on his blog Sebastian De Deyne shares a few services and tools he uses to help him with naming things.

One of the hardest (and sometimes frustrating) tasks in a programmer's day-to-day workload is naming things. When I have a hard time finding that perfect word, I generally wind up in one of two situations:

• I have a plausible name in mind, but I'm not entirely satisfied with it
• I have no idea what I could possibly name it

Luckily, there are tools out there that can be of help.

https://sebastiandedeyne.com/posts/2018/a-pair-of-helping-hands-when-naming-things

Read more

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

Martin Hujer shares some pretty good tips for working with Composer.

Although most PHP developers know how to use Composer, not all of them are using it efficiently or in a best possible way. So I decided to summarize things which are important for my everyday workflow.

The philosophy of most of the tips is "Play it safe", which means that if there are more ways how to handle something, I would use the approach which is least error-prone.

https://blog.martinhujer.cz/17-tips-for-using-composer-efficiently/

Read more

In a new post to his site Mathieu Napoli makes the case for organising your code based on it's function rather than it's type.

We recently discussed 2 topics seemingly unrelated with my colleagues at Wizaplace: how to organize code? How to organize teams? ... Organizing code into domain modules is not a silver bullet but it forces to better understand the problem we are solving and better structure our code.

http://mnapoli.fr/organizing-code-into-domain-modules/

Read more

Frederick Vanbrabant published another delirious rant on his blog. This time it's about atomic commits.

Atomic commits, sometimes also called micro commits, is the practice of explaining your thought process in the form of commit messages and code. It comes down to documenting the way to the solution.

https://frederickvanbrabant.com/2017/12/07/atomic-commits.html

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]

Probably you know that that keeping the disk & transfer size of a JavaScript file low is pretty important. But have you considered the time needed to parse and compile the code? In this great post on Medium Addy Osmani, an engineer at Google, explains the complete cost of having JavaScript on your page.

As we build sites more heavily reliant on JavaScript, we sometimes pay for what we send down in ways that we can’t always easily see. In this post, I’ll cover why a little discipline can help if you’d like your site to load & be interactive quickly on mobile devices. tl;dr: less code = less parse/compile + less transfer + less to decompress

https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e

Read more

My colleague Brent published a new blogpost on how the ternary and null coalescing operators work in PHP.

You've probably used the ternary ?: and the null coalescing ?? operators in PHP. But do you really know how they work? Understanding these operators makes you use them more, resulting in a cleaner codebase.

https://www.stitcher.io/blog/shorthand-comparisons-in-php

Read more

???? 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]

? Symmetry in naming is a powerful tool I never gave the weight it deserves. Embrace the visual relation! A common example in Vue: pic.twitter.com/QEBbHDUvWY

— Caleb Porzio (@calebporzio) November 9, 2017

Read more [twitter.com]

Harry Roberts makes the case for making technical debt visible instead of trying to hide it.

This means that, although far from ideal, the impact of these hacks is well contained and signposted, meaning that they won’t slip through the cracks and remain hidden in the codebase for the next five years.

This pragmatism and lack of stubbornness can make your codebase much more malleable, resilient, and ultimately much more useful. Everything is a compromise.

https://csswizardry.com/2017/10/airplanes-and-ashtrays/

Read more

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

You can spend a lot of time to make emails look pretty, but it might be better to just don't style them at all. Greg Kogan did some A/B testing an concluded that sending plain emails results in more opens, clicks, replies, ...

Why are the plain emails crushing the performance of designed emails?

• They're less likely to be caught in spam filters. Having less HTML and fewer non-text elements such as images lowers the likelihood of triggering spam filters. You can use a free spam checker to validate this by testing plain and designed emails.
• They're less likely to go into the "Promotions" tab in Gmail (used by ~16% of all email users), for the same reasons above. From my testing, the plain emails typically end up in the Updates tab and some times even in the primary tab. Of course, the text in the email also affects this.
• They don't look like advertisements. The second the recipient interprets your email as an ad, promotion, or sales pitch—and it does take just a second—its chances of being read or acted upon plummet towards zero. A plain email leads people to start reading it before jumping to conclusions.
• They feel more personal. It's no handwritten note, but it's much more personal than an over-designed email with the recipient's first name crammed somewhere inside.

https://www.gkogan.co/blog/dont-design-emails/

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

A few ways to clean up the conditional code that forms most of your codebase. From simple to nested to spotting unnecessary conditions. ? pic.twitter.com/qGVaDl3TKt

— Jason McCreary (@gonedark) October 26, 2017

Read more

In his excellent talk given at Laracon Online 2017, Adam Wathan argues that testing in isolation leads to brittle test and that integration tests are much more valuable.

Read more

In a fantastic post on his blog, Kent C. Dodds makes the case for focusing on writing integration tests, and stop going for 100% code coverage. Amen to that!

You may also find yourself testing implementation details just so you can make sure you get that one line of code that’s hard to reproduce in a test environment. You really want to avoid testing implementation details because it doesn’t give you very much confidence that your application is working and it slows you down when refactoring. You should very rarely have to change tests when you refactor code.

https://blog.kentcdodds.com/write-tests-not-too-many-mostly-integration-5e8c7fff591c

Read more

The maintainers of Vue.js have recently published their official style guide.

This is the official style guide for Vue-specific code. If you use Vue in a project, it’s a great reference to avoid errors, bikeshedding, and anti-patterns. However, we don’t believe that any style guide is ideal for all teams or projects, so mindful deviations are encouraged based on past experience, the surrounding tech stack, and personal values.

For the most part, we also avoid suggestions about JavaScript or HTML in general. We don’t mind whether you use semicolons or trailing commas. We don’t mind whether your HTML uses single-quotes or double-quotes for attribute values. Some exceptions will exist however, where we’ve found that a particular pattern is helpful in the context of Vue.

https://vuejs.org/v2/style-guide/

Want to see some more style guides? At Spatie we have a guidelines site containing styleguides for Laravel and JavaScript.

This site contains a set of guidelines we use to bring our projects to a good end. We decided to document our workflow because consistency is one of the most valuable traits of maintainable software.

The contents of this site exist for ourselves—more importantly, our future selves—and for giving future collegues a reference to our way of doing things and their quirks. The guidelines cover workflow, code style, and other little things we consider worth documenting.

https://guidelines.spatie.be

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