Back in 2020, I was invited by a professor (who happens to be a friend of mine) from the Tecnologico de Monterrey to have a Q&A session around what I worked in back then with it’s course students. Due to pandemic, the session was hosted virtually and today I stumbled across the questions that I was asked then. Since I really enjoyed that moment for igniting the open source passion to potential newcomers, I’m sharing the content of such questions (and my replies to those):

I have a hobby about mechanical keyboards (nothing serious just yet). One of the issues I had recently was about me modifying some layout options; specifically I swapped the esc with the Caps Lock key. This is pretty straightforward thanks to gnome-tweaks: Open gnome-tweaks Click on Keyboard & Mouse Click on the Additional Layout Options button Click the Caps Lock behavior drop-down option Select Swap Esc and Caps Lock From here all is OK, but then I entered the programmable mechanical keyboards.

One of the things I worked on in a previous (golang) project was to interact with a C library which used bitfield structs, so it was a matter not only of interacting with C code, but also moving bits around to make sure that the data representation was not being corrupted between C bitfield structs and golang structs back and forth. This post is a reminder for myself of how it was done, in case I forget in the future (which is really a matter of whether will I forget in 2 or 4 months).

Today I just learned about a quirk when building a shared library. I wanted to link against an example library that I built with meson, but I kept getting link issues, namely undefined reference to `func_name' I later on built it manually and inspected the resulting shared object with nm, the relevant difference was about # built with meson 0000000000001263 t func_name # built manually 0000000000001263 T func_name The difference is about the lowercase/uppercase T, as NM(1) man page suggest:

This recipe is one of my favorite ones, on top of it it’s also very easy to follow and it’s nutrient complete. Ingredients 1/2 Chicken breast 1/2 White onion 2 Chayotes 2 Potatoes 3 Carrots 1 Lettuce Heart Creme Table salt Tostadas Procedure Chop the chayote, potato and carrots into small cubes (around 1/4 of an inch) and cook them by steam, once cooked, let them cool down. Cook the chicken breast with the white onion, and pull it (so it’s pulled chicken breast).

We tried different recipes for this dish, however we found the following to be the best (for our own taste) and it also tastes closer to the one sold in commercial restaurants in the city. Ingredients 2 tbsp of chicken broth (Knorr suiza) 750g Steak thin sliced (cut in small pieces, around 1x1") 500g Small green tomatoes 1 small bundle of cilantro 2 Garlic clove 250g White onion 250g Bacon 1 bundle of Cambray onions 7-8 tiny potatoes Table salt Pepper (Optional) Lemon juice (Optional) Chopped cilantro and onion Procedure Boil the tiny potatoes and the green tomatoes together in a pot.

These enchiladas are not probably what the Mexican food is generally about, however, these are the ones I’m used to since I have memory, so to me these are the best. Besides, they are oil-free and they are vegetarian. They could also be accompanied with beans or some boiled potatoes (served separately) in order to give it a flavor boost (my father usually has a cup of cooked beans’ water, for example).

4 - Comments The most valuable code is the one that does NOT need to be written Do NOT comment incorrect code, it’s better to rewrite it There is nothing more useful than a comment in the right place, on the other hand, there is nothing worse than incorrect comments There is nothing more harmful than an old comment that lies and misinforms The older and farther away is the comment from the code it describes, the more probability of it being wrong They are a necessary evil When a comment is written, thing if there is no other way to express it in the code An inaccurate comment is worse than no comment Only the code speaks truth about what it does An useful comment is when it clarifies content that cannot be modified to be improved (as using things from external libraries) The TODO comments are NOT an excuse to keep incorrect code Do NOT use comments if a clear function or variable can be used instead If a comment is written, it must describe the code around it, never information about global state The link between a comment and the code it describes MUST be evident, if you bothered on writing the comment, the least you can do is to make sure the reader will understand its meaning A short function requires no explanation and a good name works best than a comment in the function header Do NOT compensate incorrect code Incorrect code is the main motivation to write comments A clear and expressive code is much better than a complex one full of comments, instead of investing time commenting the code, fix it Legal comments Those by enterprise standards, such as copyright (they are NOT legal contracts, whenever possible, refer to a standard license or an external file) Documentation comments There is nothing more useful than a well described public API Incorrect comments Are an excuse of poor code Adding comments for no reason or just to follow a process are an error, if time is invested on writing comments, make sure it’s the best that can be written Any comment that forces the reader to look its meaning elsewhere, has failed to communicate and it does not deserve the bits its using A redundant comment that explains how the code works is an error A confusing or inaccurate comment can be a future headache Comments about changes (changelogs) were necessary before Version Control Software, Today are irrelevant and must be removed Comments used as markers are appealing if they are not abused, they will be ignored otherwise.

Chapter 3 (Functions) To do software is like any other creative process, ideas are structured first and the message latter, until it can be well understood. The first draft may not be organized, but it’s refined and improved until its right. Must be of reduced size (10 lines, max) Maximum nesting of 2 levels, otherwise makes it harder to read Do something or do respond something, not both (changes the state of a struct/object or it returns information about it, making both creates confusion) Do a single thing MUST do only a single thing, do it right and be the only thing it does Functions that do a single thing can’t be split into sections Functions do a single thing if their instructions are at the same abstraction level The code should read as a text (top to bottom); the first paragraph P0 describes a level of abstraction, the second paragraph P1 details the abstraction of the fist instruction of the previous paragraph (P0) and so on, in such a way that each one describes the abstraction level, whilst it references following paragraphs of the next level.

Chapter 2 (Meaningful names) Create correct names The length of a name MUST match it’s scope size The name of a class MUST NOT be a verb Methods MUST have verb names Don’t be afraid of changes regarding variable names (as long as it’s for the better) Reveal the intention Why does it exists? What does it do? How it’s used? If a name requires a comment, then it’s not revealing it’s intention Avoid disinformation DO NOT user names which are away from it’s intended usage meaning Avoid names with minimal variation: MethodUsedForHandlingOfStrings MethodUsedForEfficientStorageOfStrings Meaningful distinction DO NOT create code targeting only the compiler/interpreter Names with numerical series (a1, a2) do not hold an intention, they misinform Additional words are redundant (e.