Programmers like compact code. If implemented correctly, it should be easy to read and contains no parts that make you think about it more than necessary.
Is it worth using libraries for the sake of a few simple functions? Wouldn't writing them yourself be easier? These questions regularly come up with novice developers. They are asked by almost everyone who does Hexlet projects. Let's take a closer look.
You can write any code inside files (and outside definitions) in scripting languages like JavaScript: function definitions, function calls, and variable definitions and changes. This freedom simplifies development by enabling the creation of one-time scripts for simple or occasional tasks. On the other side, a careless development process leads to flaws that make the code and its maintenance significantly more difficult. They are so common in production code that we must discuss them separately.
In dynamic languages, code files can be either executable scripts or modules. These files have different limitations, are arranged differently, and behave differently depending on the role.
It's easy to create functions, but it's far more difficult to do it correctly. Poorly designed functions are frequently rewritten, have difficulty adapting to new requirements, and are poorly tested. We'll look at key methods of how to correctly share responsibilities, build function chains, and design function signatures in this article. 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 close to the real world, done outside the Hexlet environment on your own computer.
This article outlines how projects work, how long they take to complete, and why poor code won't work. The text contains our students' impressions of working on the projects.
There are two approaches to writing code: top-down — descending, and bottom-up — ascending. In the first case, high-level logic is implemented first, followed by diving into the details. In the second, everything is reversed — the details come first, and then the general logic.
These approaches are frequently contrasted in books. It is considered that if one approach is chosen, then the second one is excluded. However, this is not the case. In the article, I will explain why following only one direction causes problems.
In this article, I will discuss non-obvious bad function design decisions. Optional parameters in JavaScript, flag handling, violation interfaces, and the misuse of the rest operator.
Variables or constants declared at the module level can be imported in other parts of the program in some languages, such as Python or JavaScript. 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, and so on. On the other hand, it becomes much easier to write poorly maintained code.
In dynamic languages, there are two main approaches when designing the input parameters of 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, both explicit and implicit methods of passing arguments are equally common, and, at the same time, it’s not always clear which one should be chosen for a given function. That's what we're going to discuss.
