DEV Community: Daniel PL

Clean code by Robert Cecil Martin: My takeaways

Daniel PL — Tue, 20 Sep 2022 06:52:21 +0000

Another great book I've had the time to go through. The insights and advice given by Robert Cecil Martin are the result of years of experience in the field.

So as usual, I'll summarize my takeaways, those that as a developer I want to keep in mind.

What is clean code?

So far, the best definition of clean code I've read in the book comes from Michael Feathers.

Clean code always looks like it was written by someone who cares

And I couldn't agree more. When code is written by someone who cares it's easy to read, pleasant and will tell you precisely what you need to know about it.

The boy scout rule

Leave the campground cleaner than you found it.

It happens to all of us. You have to develop a new feature in an existing code base, or fixing a bug. If you are going to touch a part of the code base, why not leave it better than it was before?

But wait, I might hear you saying "But what If I break something?". That's what unit tests are for ;)

Naming

The book also focuses a lot on naming things properly. Functions, variables, classes. They all should have intention-revealing names.

Classes should have nouns or noun phrases.
Methods should have verbs or verb phrases.

And the length of a name should be related to the size of its scope. The broader the scope is, the larger the name should be.

The paperback model

The author is responsible for making himself clear, and not the academic model where the scholar has to dig the meaning.

The code should be self-explanatory, and clear to the reader. The developer who is going through the codebase shouldn't have to have a hard time trying to understand what the previous developer meant.

The responsibility and the effort are on the developer who is writing the code to make it easy to understand. And not with comments, with code!

Overloaded constructors

When constructors are overloaded, use state factory methods that describe the arguments instead.

An example given in the books is:

Complex fulcrumPoint = Complex.FromRealNumber(23.0):
is generally better than
Complex fulcrumPoint = new Complex(23.0);

The rules of functions

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

Code in conditionals and whiles

The blocks within if statements, else statements and while statements should be one line long.
If it can't fit in that, use a function.

Flag arguments

If you have to pass a boolean flag to a function to determine its behavior, that function is doing more than one thing and violating the SRP principle.

That function should be split.

Function with too many arguments

When a function needs more than two or three arguments, some of those arguments can likely be wrapped into a separate class.

Functions responsibility

A function should either do something or answer something. Not both.

Comments

Comments are, best case scenario, a necessary evil. Comments are there to compensate for our failure to express ourselves in code.

So if you have to comment something out, you haven't done a good job expressing in code what you intended to do.

Dependent functions

Whenever a function calls another function, it should be vertically close in the code, and the caller always be above.

Nulls

Returning null from methods is bad, but passing null into methods is worse.
Except for API that might force you to do that.

So don't return nulls.

TDD Laws

First Law: You may not write production code until you have a written failing unit test.
Second Law: You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
Third Law: You may not write more production code than is sufficient to pass the currently failing test.

If you want to see also Robert in action explaining TDD you can check one of his talks here.

F.I.R.S.T

Clean test should follow five rules:

Fast: They should be fast and run quickly.
Independent: They should not depend on each other.
Repeatable: They should be able to run in any environment.
Self-validating: They should have a boolean output.
Timely: They should be written in a timely fashion. So, the test is written before the production code, not after.

Classes

Classes should have a small number of instance variables. Keep the cohesion low.

If a few functions share the same variables, split them into a separate class.

SOLID principles

The single-responsibility principle: There should never be more than one reason for a class to change.
The open-closed principle: Software entities should be open for extension, but closed for modification.
The Liskov substitution principle: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
The interface segregation principle: Clients should not be forced to depend upon interfaces that they do not use.
The dependency inversion principle: Depend upon abstractions, not concretions.

You can find more information here.

The principle of least surprise

If you do something in a certain way, do all similar things in the same way. Keep the consistency.

The pragmatic programmer: my takeaways

Daniel PL — Mon, 29 Aug 2022 07:04:31 +0000

I have recently finished the book 'The Pragmatic Programmer:
Your journey to mastery'.

A very interesting reading, packed with tips and ideas to improve as a developer.

So I've decided to write down here my personal takeaways. They might not be the best ones, but they are at least, the most relevant for me.

I hope you like them.

1. Does your work environment suck or you find your job boring? Do something about it.

“Does your work environment suck? Is your job boring? Try to fix it. But don’t try forever. As Martin Fowler says, “you can change your organization or change your organization.”

Try to fix whatever is wrong with your work environment, if you can't, change jobs. So far, our industry and the market is giving us that opportunity. Embrace it.

2. Don't make lame excuses

Before telling anyone that something can't be done or whatever excuse you're going to say. Stop and think about it. Is it a lame excuse? How will it sound when you say it?
Instead, come up with options.

3. Don't leave broken windows

In the book, they explain the concept of 'broken windows'.

The concept is simple. If you leave something broken or in a bad state, that reinforces the idea that either nothing can be fixed or that no one cares.

The same happens with software, do not leave broken windows, if you find one, fix it or find the time to do it (and actually do it). Needless to say, do not break windows by yourself.

4. Keep an eye on the big picture

If you don't see the big picture, you'll miss everything happening around you and you won't be able to react properly.

5. Invest in yourself

Invest in your knowledge portfolio regularly
- Even if it's only a bit every day
Diversify your knowledge
- Do not focus only on one technology/language/framework
Manage risk
- Evaluate which technologies/languages/frameworks are better to invest in than others
Emerging technologies
- Keep an eye on what is coming or new, being an early adopter, if it takes off in the market, can put you in a very valuable position.
Keep always yourself up to date
- Same as we do with our OS and libraries, keep yourself up to date

6. Be part of the community

Find out what people are working on these days, especially outside of your company and actively participate in discussion groups.

7. Make your code easy to change

If your code is easy to change, it will most likely be well designed and decoupled.

8. DRY

The DRY (Don't Repeat Yourself) principle does not apply to code duplication, it applies to which intrinsic knowledge the code contains.

“DRY is about the duplication of knowledge, of intent. It’s about expressing the same thing in two different places, possibly in two totally different ways.”

You might have two pieces of code that are exactly the same, but they are intrinsically expressing different knowledge. That is not a violation of DRY.

9. Keep your code decoupled

Try the Law of Demeter in your code, to make sure you write modules that don't rely on other modules.

10. TDD and unit tests

Use TDD and write unit tests.

11. Prototyping is a learning experience

The value of prototyping is the learning, not the code itself. So don't be afraid of missing error handlings, using dummy data or not having the most complete functionality.

The prototype is not the final product.

12. Find better ways for repetitive tasks

If you find yourself doing the same thing multiple times, ask yourself if there is a better way.

13. Engineering daybook

Write down all the learnings, keep it in some doc, notes, whatever. So you can go and check it out in the future if needed.

14. Write shy code

Be clear and strict on what the code is expecting as an input and promise as little as possible in return.

15. Don't chain method calls

Try to avoid more than one "." when accessing something.

Example from the book:
amount = customer.orders.last().totals().amount

16. Refactor is not a full-on rewrite

Don't fool yourself, a refactor should not take week/s of work. Refactor is something small.
And keep in mind a refactor or full-on rewrite it's not meant to add new features. That comes later.

17. Naming things

Naming variables, systems, functions and so on is a big part of our work. And let's be honest, we are usually not good at it. Name things according to the role they play.

And that was it

There are way more tips, and very well explained in this book. These are, in my personal case, the ones that I want to keep in mind the most and put into practice more often.

Have you read the book? If so, which ones do you think are the most important for you?

If not, what are you waiting for? Get the book, some tea and enjoy :D

Is Bun so much faster than Node.js?

Daniel PL — Tue, 26 Jul 2022 06:29:27 +0000

It seems like Bun is the new cool kid in the javascript runtime scenario. Looks very promising and all of that, but, is it that fast?

I will do a set of simple tests, to see if even on a small scale the performance difference is already noticeable.

Today I will focus only on requests performance and operations per second.

Setting up Bun

But first, I'll start installing bun in the bun directory

curl https://bun.sh/install | bash

And creating a basic response

// http.js
export default {
  port: 3000,
  fetch(request) {
    return new Response("Welcome to Bun!");
  },
};

Setting up node

Now I can move on to node. Because I already have Node.js installed I just have to create a basic response as well.

const http = require('http');

const hostname = '127.0.0.1';
const port = 3000;

const server = http.createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Hello World');
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});

Now I'm ready to have fun.

Http request performance

For the HTTP request performance, I'll test both implementations using Artillery.

Artillery can be installed through npm

npm i artillery

And comes with a nice CLI to execute a quick load test.

 artillery quick --count 500 --num 100 http://localhost:3000

This will run 500 virtual users with 100 requests each.

The results are the following:

http	node	bun
http.codes.200	50000	50000
http.request_rate	1585/sec	1617/sec
http.requests	50000	50000
http.responses	50000	50000

http.response_time	Node	Bun
min	0	0
max	143	73
median	32.8	22.9
p95	63.4	36.2
p96	100.5	50.9

vusers.session_length	Node	Bun
min	1835.3	1103.1
max	4989.2	2805.9
median	3678.4	2566.3
p95	4770.6	2780
p99	4867	2780

(in milliseconds)

The results are far from the claims in performance from Bun, but still, very solid. In all aspects, Bun stands out as the winner.

Operations per second

Here I'll do a test of just calculating prime numbers, to see how long it takes for each one.

To test the calculation of prime numbers I will execute a very simple code and make use of performance.now() to measure the execution time.

(function (maxNumbers = 30000) {
  let start = performance.now();
  let primeNumbers = []
  let numberToCheck = 1;
  while (primeNumbers.length < maxNumbers) {
    if (isPrimeNumber(numberToCheck)) {
      primeNumbers.push(numberToCheck);
    }
    numberToCheck++;
  }

  console.log(performance.now() - start);
})();

function isPrimeNumber(number) {
  for (let i = 2; i < number; i++) {
    if (number % i === 0) return false;
  }
  return true;
}

The results for calculating prime numbers are the following (in milliseconds):

prime numbers	node	bun
100	1.035	0.618
500	4.5071	3.223
1000	9.3060	8.680
5000	209.8485	198.4309
10000	909.618	849.832
30000	9113.5302	8559.282

This time the results are not that different, but Bun wins again.

Bun is still in beta version, and we should keep that in mind. If at this stage the results already look promising, interesting times will come if the improvement continues along the same lines and, who knows, maybe in some years Bun will find its place on the market.