Programmers like compact code. If it's done correctly, then it should be easy to read and shouldn't contain any parts that make you think about it more than necessary.
Is it worth using libraries for a few simple functions? Wouldn't writing them yourself be easier? These are questions regularly asked by novice developers and by almost anyone working on Hexlet projects. Let's take a closer look.
You can write any code inside files (and outside of definitions) in scripting languages like JavaScript. This can be defining and calling functions, or declaring and changing variables. This freedom simplifies development by allowing you to create one-time scripts for simple or infrequent tasks. On the other hand, careless development leads to flaws that make the code and maintaining it significantly more difficult. They're so common in production code that we need to address them separately.
In dynamic languages, code files can be either executable scripts or modules. Each of these kinds of files have their own limitations; they're arranged differently, and they behave differently depending on their role.
Creating functions is easy, creating functions properly is harder. Poorly designed functions frequently have to be rewritten, it's difficult to adapt them to new requirements, and they don't get tested properly. In this article, we'll look at key methods for sharing responsibilities, building chains of functions, and designing function signatures. The article's content is based on common mistakes made by Hexlet students in their projects.
According to our students, projects are one of Hexlet's strongest features. These are special tasks that closely mimic real-world tasks, and they're done on your own computer, outside of Hexlet tasks.
This article outlines how projects work, how long they take to complete, and why poorly written code doesn't work, and it also contains thoughts from our students about our projects.
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.
