Now that I have trekked these past 6 weeks from the southern shores of simple
A perfect example of the divide in how logic is treated differently is the fact that unless a value is explicitly returned using the
This flies in the face of Ruby conventions that favor implied returns at the final line of a method. But if one thing has become clear so far on my journey of learning to code, it is that repetition breeds knowledge and knowledge breeds skill. In other words, doing things in a standardized way helps cement concepts. To that end, I have found that using either a commented
return above my last line or actually applying the
return bare word to my last line in Ruby helps me stay grounded across both languages.
do blocks found in Ruby, but they have a very important difference.
doblocks in Ruby do not trigger if either their condition isn't met or the iterator they are passed to is unable to fire at least once.
doloops evaluate their condition only after executing their code.
This means that
The differences in how
Some situations will still require you to employ the
do end syntax, such as embedding logic into
.erb files. But for the most part, the best way I have found to develop cross-language muscle memory is to pass blocks in Ruby using curly braces whenever possible.
The added advantage to adopting this syntax is it leaves the possibility open for method chaining for those occasions where the rule of adhering to functional readability can be flexed to write logic as a single line.
The case for using curly braces over
do end is strengthened by adding shorthand
key: value hash notation into the mix. When used in combination, these conventions of syntax apply to not only JSON but also CSS, creating a much more unified vocabulary of muscle memory overall.
While there are solutions for this as mentioned in this article by Kevin Kim that are functionally synonymous with
These situations do not necessarily imply that a given project will be created on NodeJS or that a given bug will crop up when testing in Chrome. This means that despite having utilities available under NodeJS or Chrome's developer tools, there will be times where these may not apply.
Enter our hero:
The simplest explanation of how
console.log() works is that it is a utility function that prints a copy of its string argument to the console window of the browser. By interpolating variables into a string using template literals, an approximation of the same behavior as
pry can be achieved; albeit not as user friendly.
It is important to note that depending on the scope of the function where
console.log() is called, it may be impossible to render the output of the function in the console.
Because of this, it is best to be aware of how to use
console.log(), but factor in the availability of debugging tools when deciding how to develop the front-end code of a project.
Thankfully, the learning curve for interpolating variables into strings is a lot more straight forward. The syntax is nearly identical, as shown here.
"Interpolating variables is 'gravely' important"
Class.new in Ruby, now we have to come to terms with
new Class(). It may seem like a small difference, but it can have quite an impact on the flow of a project.
Because the majority of the class instantiation I write in Ruby now occurs inside of Rails controllers, a strategy that I have found for standardizing between these two syntaxes is to completely abstract my
#new action into a
before_action helper method. This simultaneously declutters my code and allows me to mentally conceptualize these two situations as unique, evading crosstalk.
Now that we are taking how classes are instantiated into consideration, let's step back a moment and review how helper methods like
before_action are defined. According to Rails convention, these methods are defined below the
private bare word in Rails, but with a lot more work and high level understanding involved.
Currently, the intricacies of available means of privatizing class properties and methods extends beyond the scope of my skillset and the topic is a very deep rabbit hole that exceeds the reach of this article. More information about this process can be found here by Chris Ferdinandi.
One prime example is assigning a value to an object property that does not exist, thereby creating and appending it to the object in the process.
Unfortunately there is one elephant of syntax difference in the room that is large enough no amount of workflow adjustments in either language can hide it. This elephant is the diverse ways in which the structure of statements and the use of bare words differ between these two languages.
Due to the breadth of the information regarding exact syntactical differences you will encounter, I recommend reading this excellent article by Edozié Izegbu to better prepare for these inevitable sticking points.
While my journey of learning to code is only just beginning, I hope that these strategies can help to guide or inspire you to begin standardizing how you approach writing in multiple languages.