Blog Post

As programmers we are too often judged solely on the basis of our knowledge. Despite the fact that the whole world claims that a programmer should not learn commands or instructions by heart, often in interviews even with large-scale companies, the resolution of certain problems by means of specific languages ​​is still required.

Instead, what I like to think is that one day the word ‘programmer’ will be replaced by the word ‘developer’, so sumptuous in its pronunciation. Very often developers base their choices on a few rules, but all centered on fundamental principles common to every language. What I have tried to do in this article is to collect and summarize those principles or at least those that I consider fundamental.

The comment as a double-edged sword
The biggest problem that the comment brings with it is that it needs to be updated with the functioning. To give a concrete example, it’s a bit like an automatic test: you write a logic and design an automatic test that uses this logic, then it ends up changing the starting logic and promptly the automatic test breaks.

At this point, if you haven’t set up a GitHub action that runs tests on every commit, you’re screwed. You don’t realize that the self-test is broken until you’re done with development, maybe weeks later, and then you don’t remember anything. The comment is essential, but it’s only useful when updated. The advice is not to comment out pieces of code that change often, but if a piece of code gets called often and hasn’t changed in months, then that might be a good place to start. Don’t hurt yourself by commenting anything though.

Code splitting
Just as Javascript code is split when it is sent to the browser, source code must also be split before it gets to the development team. While Javascript can be divided into blocks according to the page it belongs to, the source code must have a logical division, which unfortunately is not always immediate.
It’s not necessary to categorize each individual into its own singular folder, but it’s incorrect to place a well-written class haphazardly inside a codebase folder. The happy medium I would say is a 3 level categorization. In fact, the human brain struggles to remember the great-great-grandparent node in a hierarchy, so it is better to keep a simple tree.

I often use the ‘filename.filetype.ext‘ convention, which, given how it is structured, helps to remember the logic with which this file must be modified.

Look for the middle ground in categorization.

Order vs Speed
In order to be fast, certain algorithms need to use constructs and techniques that are not always easy to understand. Very often, for example, it is necessary to use indexes to access an array and add them, incurring annoying and useless headaches, especially when re-reading these codes after a long time. Sometimes, however, certain optimizations are imperceptible and unnecessary in relation to the amount of work that the routine lends itself to carry out.
There’s no need to write a super-optimized sorting algorithm when there are fifteen items to sort. Sure, you lose in performance and computational speed, but you gain in design speed and above all in legibility.

Nomenclature
Who hasn’t happened to read a piece of code written by others and find variables a, b, rt, pci, pls or some other strange and incomprehensible acronym?
How annoying when that happens.

In LH we have come across a codebase where the word WES occurs very often and we still don’t know what its meaning is. Imagine then that someone comes along and needs to be explained precisely what the software does, and that you hear WES repeated six or seven times in thirty seconds, without being able to explain what it means.
Being able to give a correct and concrete name to each variable can therefore be a difficult task. I personally prefer to have a slightly longer-to-read variable that fills more characters on the screen, but explains exactly what its reason for existence is.

Team Get organized with colleagues
Even if you’ve been working on the same thing for weeks and you already know exactly what the developer is doing who touches the same project as you, talk to him before putting your hands on the keyboard, to understand if he intends to modify your own files, if wants to introduce radical changes or if he wants to make changes that perhaps you would have done in a different way. Maybe he needs some advice.

Keep the dialogue open, send him the video of the podcast you follow on artificial intelligence, web3, programming of embedded devices to monitor the heartbeat of dogs. Maybe he too has some interesting news to share with you, which could potentially revolutionize your day.

Every great project always needs many heads.