Using Good Coding Practices in Sinatra
Even though I officially started my Flatiron School education on November 9th. I consider it to have started around July 20th. I consider that to be my start date because that was when I started taking the lesson on learn.co . From those lessons, the First Mile, and then the CLI project, I had a hard time getting on a roll with coding. It was not that I did not like it, but for me, it was difficult to grasp certain concepts because there was no visual element that went along with it. I’m a comic artist, so I guess it’s not a surprise that having a visual that went along with the code would help. I’ve had many a great night working hours upon hours coloring comic pages in photoshop. While Photoshop and coding have many differences, they do have some things in common. They both seem impossible to grasp when you start, but once you begin to understand it a little bit, and actually get to build a project, they can be really fun and exciting to use.
I’ve started to have that experience during the Sinatra project. With having the website, I could actually see a visual manifestation of what the code was performing. It made the process much funner, and instead of being relieved just to get the project done, I’m looking forward to building the project out beyond the mandatory requirements. Here are a couple of valuable insights on coding that I learned throughout this project.
Storing Repeating Code in Variables
One of the core concepts that Flatiron School is that repeating the same line of code over and over again in various methods is not necessarily the best practice. While definitely understanding that, I understood why we do that even better through this experience. Not only is it tedious writing the same line of code over and over, it can also really hinder a project or simply keep it from working in any capacity. As anyone who has any degree of experience coding knows, syntax errors can be very annoying but very easy mistakes to make. Just like doing one’s own proofreading right after writing, it can be very hard to spot our own mistakes, and the same principle applies to coding.
For this project, it was crucial that users must sign in before they can start using the site and posting their own data. This meant that our program had to recognize the user’s id before they were allowed to proceed on the site. If the program did not recognize the user’s data at the login, or insufficient data was given at signup, the user would simply be redirected to those respective pages. This meant that every get method within the controller would need to have a line of code that would need to ensure that the user was logged in before the user was allowed to view the page, and be able to create, read, update, or destroy data.
The line of code that accomplished this task was User.find_by(id: session[:user_id])
This line of code was actually valuable to use for a couple of different methods. One was the logged_in? method, which had to be posted at the start of all get methods to validate that the user id. Then there is the current_user, or in this case, given the spirit of the application, the current_pizza method. The current_pizza method was used so the program would recognize that pizza places belonged to a specific user who submitted it.
That gave two methods that looked like the following:
def logged_in?
User.find_by(id: session[:user_id])
end
def current_pizza
User.find_by(id: session[:user_id])
end
While this would work, we’re still repeating ourselves. Is there a way for one method to call on the truthiness of the other? You bet there is!
def logged_in?
!!current_pizza
end
def current_pizza
User.find_by(id: session[:user_id])
end
There we go!! We’re being clear about what we are trying to accomplish with our code while also not being repetitive.
