There are two approaches to writing code: top-down and bottom-up (descending and ascending). With the top-down approach, high-level logic is implemented first, followed by the details. With the bottom-up approach, everything is reversed; the details come first, followed by the general logic.
These approaches are frequently contrasted in books. It's generally considered that if you choose one approach, then you have to exclude the other one. However, this is not the case. In the article, I'll tell you why only going down one path can cause problems.
In this article, I'll look at bad function design decisions that don't seem too bad at first glance. Optional parameters in JavaScript, flag handling, violation interfaces, and the misuse of the rest operator.
In some languages, such as Python and JavaScript, variables and constants declared at module level can be imported to other parts of the program. On the one hand, this opens up a world of possibilities when compared to languages that require all data to be contained within functions, classes, etc. On the other hand, it makes it much easier to write code with issues.
In dynamic languages, there are two main approaches when choosing the input parameters for functions: the first is to use explicit, positional arguments, and the second is to pass a structure containing everything that the function expects. In real code, passing arguments implicitly and explicitly are equally common, and it’s not always clear which one should be chosen for a given function. That's what we're going to look at today.
All of our students come to Hexlet with a certain amount of educational experience, at least at school or university. This experience forms not only the idea of what the learning process should look like, but also their very attitude toward learning. Unfortunately, sometimes this can stunt development. Habits and attitudes built up over time often prevent people from seeing alternative options. In this article, we'll take a look at a few common student attitudes about learning and try to see how true they really are.
At some point during the learning process, you'll find that expectations don't match reality, and you don't see the desired result. There can be many reasons, but among them are those associated with cognitive distortions. This is the type of reason we're going to talk about here.
Each of us has our own ideas about what learning should be like. They are based on past experiences, other people's stories, and certain ideals.
These perceptions often differ from how the process of becoming a good developer actually works. Students may feel that they're being taught incorrectly or burdened with unnecessary knowledge. Everyone's had an experience like this at school or university. Hexlet is no different. In this article, I'll explain some theoretical basics of the learning process and give you a different perspective on what is going on around you. This will help you to improve your learning and cope with difficulties more easily.
Reading is important. However, the process of reading matters just as much. On the one hand, you don't want to miss useful information, on the other hand, trying to understand and comprehend every word stretches this process to infinity. Here, I'll share my way of reading. Most likely, it’s not for everyone, but, as a practice has shown, it still works for plenty of people.
This is Ruslan's story. Ruslan worked in the oil industry in Ufa, Russia but dropped everything to move to the US. He repaired household appliances and drove trucks, then he learned Java to become a programmer.
Below are the most common mistakes programmers make when naming variables and functions in their code. These examples are taken from the projects of Hexlet students. I use JavaScript for demonstration purposes only because it is the most universal language, so the examples have nothing to do with the language being used. These mistakes are found everywhere in equal proportions.
What is the most difficult part of being a programmer? Naming variables.
This thought seems to be popular among programmers for a reason; people often struggle with naming. Indeed, how we name our entities (functions/variables/constants/classes/modules) is of great significance because generally, we read code, we don't write it.
It's very easy to make mistakes when you have to handle variables, change them, keep track of them, etc., especially in a loop. A great way to understand what's going on is to use the simplest debugging tool of all — console.log.
We are launching our new study program in English. The first course — Programming fundamentals — has started yesterday, new lessons come out every Tuesday and Friday. It's free!
