I wrote this a few years ago (before 2012), about the idea that a method or function should have only one “exit point”, i.e at most one return statement. It is now hosted here for reference. Fortunately, this “law” seems to becoming less common. The article is still generally my opinion. To sum up:
There is a high bar to clear to call something a “law” and the idea that “a method should have at most one return statement” does not meet it for modern languages. There is no formal study that shows that this rule leads to safer, more readable or otherwise better code in these languages. It is therefore just a style.
It is not a useful style when applied as a blanket rule. There are cases where a single return is more readable or simpler, and cases where it isn’t. If you learn when and how to use multiple returns, you can write more expressive code.
Do not blindly follow cargo-cult rules.
This is a note on, the Turing Award laureate, Ted Codd’s revolutionary paper — A Relational Model of Data for Large Shared Data Banks. In this post, I will review the paper and add my comments with a perspective from modern distributed databases.
If you are interested in video-games hardware, the arcades of the 80’s are the source of endless entertainment. During that decade each game was designed from scratch with a new motherboard featuring various combinations of processors.
Game developers re-invented the wheel until two of them decided to standardize their hardware, propelling themselves ahead of the competition in the process.
SNK came up with the legendary Neo-Geo and Capcom had the CP-System (later known as CPS-1). While I hope someone will write a much deserved technical book about the Neo-Geo, I am focusing on the CPS-1. Today I wanted to talk about its sound system.
It’s the fourth time I’m writing a yearly “PHP in 20XX” post, and I must admit I’ve never been as excited about it is this year: we’ve seen awesome new features added to PHP, with stuff like attributes, enums, promoted properties and fibers; and on top of that, the static analysis community is making great progress, my personal favourite feature is PhpStorm now supporting generics when writing code.
Exciting times are ahead, let’s take a look at modern day PHP!
Of course the answer was “there’s just not that much linking to do”, and so any difference between
lldwas within a second. GNU ld was lagging way behind, at four seconds or so.
But in their quest for linker performance (I love that this is a thing, by the way), they told me how to profile them!
“Graphics has become too difficult.”
I have increasingly heard this or some variation of it in recent years, that graphics programming has become so complicated and difficult to learn that it’s discouraging people from pursuing it as a hobby and/or profession, or causing them to give up after they’ve started. I have a deep love for this area of programming, so this kind of commentary always hits me in the gut. Graphics programming in games is an incredibly rewarding specialization, is constantly evolving and innovating, and has (for the most part) one of the better communities in programming which thrives on sharing as much as possible. So what’s going on?
Well, it’s complicated, but they’re not wrong.
When I started making this post a couple months ago, it looked very different than it does now, and it was working towards an argument for a higher level (DX11-but-better) API wrapper for D3D12, basically. The more I wrote, the more I understood the issue was more complex than that, and then posted this poll on twitter, confirming that there really wasn’t (as one person put it) a one-size-fits-all solution for learning graphics anymore. Some might look at that and say “well, there never was one before either” and they’d be right, but the gaps have widened in recent years. Let’s talk about that.