My name is Andrew Diamond, and I’m currently in week three of my coding bootcamp journey with the Flatiron School, specializing in Software Engineering. The program is split into five phases, and I’m in the process of trying to level up to phase two after learning a bevy of integral concepts and fundamentals associated with JavaScript, HTML, and CSS, the majority of which were completely foreign to me as of one month ago.
I’ve faced a few more daunting challenges than I initially expected to by this point in the program – which is saying a lot, considering how intimidating I found the subject matter and workload volume to be in the first place…
The steeper-than-expected learning curve I’ve encountered, however, has pushed me to heights that I also didn’t expect to reach by week three of the program. I’ve seen my skills grow at a surprisingly more rapid rate from one day to the next, particularly in the last week or so, and the improvements I’m making span across a variety of topics and core software engineering principles. I believe the main catalyst for this recent uptick in skill sets has come from an adjustment I made in my approach to studying the subject matter.
My initial approach, back when I began the precourse work a couple months ago, was to create notecards for each new topic I perceived as a significant, core principle worthy of added attention, and in turn retention. I essentially treated such terms and methods like I would for a vocabulary test, by preparing notecards for each one, and then testing my knowledge of their contents on a frequent basis.
It began to occur to me over time that – unlike spoken languages, such as English, Spanish, etc. – JavaScript incorporates mathematical fundamentals (e.g. the utilization of functions as well as a wide range of other practices and methods that are mathematical by nature). After encountering my first few sets of lab assignments within my precourse workload, I quickly realized that my notecard-based studying technique was suboptimal to say the least, and that it simply wouldn’t properly equip me to solve problems with code in an efficient manner.
So, I somewhat begrudgingly pivoted off this approach that once made sense to me, and began to code as often as possible in order to create some muscle memory for it, and to gain a level of comfortability with it to the extent that it would no longer feel quite as intimidating as it did at the time. It didn’t take long for me to realize that I was picking up skills at a much faster rate than before, and that I would even surprise myself with the amount of knowledge I had gained on an occasional basis, just by continuing to write code on a more consistent basis.
One topic in particular that stands out as an applicable example for how my renewed approach paid greater dividends is that of arrow functions.
My initial understanding of arrow functions was that they were simply a shorter and more efficient way to write out, and declare a function than the standard method of function declarations.
Ok, but why…? And, how…?
“Why/How” are the golden questions that get answered when you produce good code as a software developer. If we are unable to fetch an answer to the questions of “why?” or “how?”, regardless of the subject matter , then we’re left without a major piece of the pie that stands before you – otherwise known as the logic behind how and why this pie was baked. Sometimes that’s ok in life, but I prefer to have the full fledged story of why something exists before me, and it’s what drove me into this major career change I’m now pursuing.
So, as I transitioned my learning techniques from mundane notecards to complex code-writing, I went from having a loose understanding of arrow function declarations vs. standard function declarations, to a far more thorough understanding of what they look like, what their use-cases entail, and how each of them function (no pun intended) within the body.
Technically speaking, you can accomplish the same exact goal with a standard function as you can with an arrow function. JavaScript will ingest and interpret both types of function syntax as one in the same.
So why use arrow functions?
I asked one of my course instructors this question last week, and came to the understanding that it’s important to be mindful of the eventual reader(s) of your code as you construct it, and less is always more when it comes to interpretation of code from one developer to the next. If you can fit three lines of code into one line of code, then you’re better off pursuing the latter solution between the two.
At the end of the day, the goal of this program isn’t just to have you become a functional software developer. That’s the bare minimum. The goal is to develop your skills from functional to masterful.
I can already tell that developing good habits, like producing more efficient, succinct and modular code vs. lengthier, messier, disorganized code, in the early stages of the program will go a long way towards developing my skill set to skew closer to masterful than to simply functional.
As you’ll see below, I’ve created a subtract function using both types of syntax…
*Standard Function Declaration:
*
*Arrow Function Declaration:
*
// parameter shoutout to my favorite scene from the movie “Superbad” … 😀
The difference between these two syntactic approaches may seem like more of a subtlety than a necessity for any given situation, and while that’s technically accurate, it’s always best practice to be more concise with your code. The shorter your code, the easier it is to debug your code when problems inevitably arise. As you write more and more code, you come to realize how long your code may be one way or another, so the dividends associated with deployments of arrow functions rather than standard functions can really add up over time.
So, what are the distinct differences between the two, other than one being shorter than the other?
As you’ll notice, arrow functions, like the one above, do not possess any curly braces when it contains a single expression, and that is because it operates with an implicit return value, unlike that of the standard function. This is the one and only instance in JavaScript where a function doesn’t require an explicit return with the return keyword associated within.
Curly braces do, however, need to be incorporated within arrow functions that contain more than one expression within, but in these instances, we lose the power of an implicit return, which renders the core advantage of an arrow function vs. a standard function as essentially nonexistent. It is these instances where I prefer to deploy a standard function vs. that of an arrow function.
I hope this intro blog helps other beginners attempting to grasp the differences between arrow functions and standard functions, as well grasp an overarching approach to the wide range of topics associated software engineering languages and principles.
*Resources
*
Top comments (0)