Horrible Code, Clean Performance

Horrible Code, Clean Performance - Johnny’s Software Lab.
A short tale of how horrible code yields clean performance.

Read in full here:

This thread was posted by one of our members via one of our news source trackers.

First time I encountered this is in my first job, in C/C++, years ago.
There was a part in the codebase that was really hard to understand, and I asked a senior developer about it. He said that it was written that way for performance reasons.

1 Like

Well … that’s pretty hard topic … :sweat_drops:

On one side new Elixir developers are definitely surprised seeing a solution with for example the [head | tail] notation in a recursive function. On the other side using just pattern matching in function clauses we have tons of flexibility. :exploding_head:

What is a horible code or rather what is a good code? For me the code is clean when I can describe what it do after not touching it even for let’s say 6 months. There are good and bad practices, many hints/tips as well as gotchas, but many of them are pretty specific and does not decide if the whole final code is good or not. :thinking:

Let’s then list some more generic points … What makes a code clean without affecting performance? :rocket:

  1. Follow core and community conventions like Naming Conventions in Elixir documentation or Credo’s Elixir Style Guide :memo:

  2. Write self-descriptive code i.e. avoid one-letter variables, short and cryptic names :man_detective:

  3. Write a good documentation. From user perspective (wiki), developer perspective (issue) to implementation details (pull request) in contributing part and from module/function documentation, typespecs up to guides and code examples in release part :spiral_notepad:

  4. If you have some idea, but you are not sure how to write it then search for inspiration in popular projects. Nobody expects that you know everything from start, but you should be smart enough to find what you need :mag:

  5. Follow your intuition :nerd_face:

Too generic? Such advice are everywhere? There is no short way or rather it is, but in exchange you would have a horrible code. All you need to do is to practice and without any lie examine yourself. Everyone thinking that’s boring have a really small view perspective. It’s not about be boring or not - it’s about how you would make it attractive. Everyone have different type of learning. Search for challenges in places you feel comfortable. In that way when you would be really bored you would come back for yet another challenge! :heart:

There is always someone more experienced and there is no shame in it. That’s actually a chance for you to improve. I recommend to look at José Valim streams on Twitch. They are worth to watch even when not live! At the end no matter how much years of experience you have don’t assume you know everything. :owl:

2 Likes

A good idea was written at the end of the article. That if there is a bottleneck in the program, then it will be a reasonable decision to sacrifice the purity of the code. In other cases, this is the destruction of one’s own work, because then it will be impossible to maintain it, and it will not be easy to bring the project with this approach to production. Therefore, clean and readable code should be everywhere, regardless of performance.

1 Like