1/18/2024 0 Comments Ruby on rails jobs![]() ![]() It's even harder to extend with new features and functionality, and can become a bug-prone black box that's slow and challenging to develop for. Inexpressive code can be a nightmare to maintain, and it often leads to tangled code, quickly becoming tough to modify without breaking something. By employing clear variable names and self-explanatory methods that do what they say in a fixed, predictable manner, we can automatically infer the type (or potential types) of data we're working on in any given line with little effort. In some ways, we can think of Ruby's expressiveness as an answer to a lack of static typing. It not only wastes time by forcing us to work out the possible data types of inputs, but it can also break our focus and flow, and add unnecessary cognitive overhead. Type IssuesĬonstantly having to check for potential data types and the possibility of nil values can be genuinely exhausting and really slow us down. ![]() so either they set it and it's a string, or it wasn't set, so it's nil." So they change it to if Except, what happens when the user has a value set, and then later removes it and submits the form? We'll now have an empty string (which now, without present?, evaluates as truthy). Consider a scenario where someone has just spent time cleaning up a section of code and spots something like if than stopping and thinking: "hey, there must be a reason present? was used," they might think: "hey, this particular field is optionally set by the user. On the other hand, a lack of trust can lead to bad assumptions when the right method is actually being used. In addition, we might add verbosity to our code, and send potentially misleading signals to other developers (and even our future selves) about what we're accounting for and trying to accomplish. We may wind up accounting for potential values that aren't even real possibilities, magnifying the existing problem and further eroding trust. This inevitably leads to constant defensive programming, which can serve to further muddy the waters. But when a lack of expressiveness is a pattern across our entire codebase, we lose faith in our code as a reliable source of truth to communicate the potential values it may be handling. When a particular feature or area lacks expressiveness, it can be frustrating, but it is also an opportunity to improve our app. This only serves to derail us from our task at hand, and makes our lives harder. In addition to being confusing, inexpressive code also turns the thought process of the developer who coded it into something of a black box, rather than a window into their decision-making.Īs touched on above, this can force the developer maintaining our code to delve into the implementation in greater detail than they should to get context. The most obvious issue - a lack of clarity - in addition to being its own problem, can lead to a host of other headaches: Opacity What problems do we face if we aren't conscientious about how we write and structure our code? The answer is at once straightforward and easy to forget in the moment. The Impact of Expressive Coding on Productivity Ultimately, expressive code saves us time, and our company money. Usually, any time I find myself with comments all over the place, it's a sign I need to refactor. Working with external APIs or unfamiliar gems is one thing, but generally, for most of our core functionality, writing idiomatic Ruby means we don't need to write (or read) comments. This is likely one of the reasons we often associate commented code in Ruby with bad code: because, in many cases, it is. Ruby takes to heart the principle that good code should be self-documenting it largely obviates the need for comments. Why is this important? It saves us from spending a lot of time familiarizing ourselves with the context of the code we're working on, clues us in to what we should be looking out for when we modify it, and keeps us from potentially bulldozing carefully-coded functionality and measures meant to safeguard our application. It makes clear not just what the code does, but why it was written how it was. Let's get started! The Importance of Expressiveness in RubyĮxpressive code goes beyond readability ("What does this code do?"), and clearly communicates intent: it clues us into the developer's considerations and concerns, and the edge cases they were accounting for. Then, we'll explore how to best use some of Ruby's methods. In this post, we'll look at why expressive code is important and its impact on your productivity as a developer. Methods are named very carefully, and do what they say they do they also tend to have inverse methods which do the opposite. This is no accident Matz very consciously designed Ruby as an intuitive language to more or less read like English. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |