In this week’s blogpost, after seeing a piece of code in a previous assignment I wanted to learn a little bit more about what it actually was. The piece of code in JavaScript used async and await, and me being a novice in JavaScript didn’t exactly know what it was, but did a little bit contextually. At first glance they seem like timed functions to synchronize something. In exploring what these were I came across this article on error handling in JavaScript.

https://www.valentinog.com/blog/error/

This blog goes into great detail over error handling in JavaScript, and I’ve learned quite a bit more as well as answering the async and await question.

First off, I did not know that JavaScript was single threaded, meaning that it doesn’t utilize multi-threaded processes to handle certain bits of logic simultaneously. The article gives a good example with a timed error throw with an error catcher to demonstrate how the try/catch will already execute before the error would ever be called.

I was also introduced to some new interesting features of JavaScript like Promise. Promise is indicative of it’s name and is basically like a promise of the code to catch up with each other later. Promise uses “.then”, “.catch” and “.finally” where the only real difference is in name for “.then” as it’s the counterpart to “try”. It also has some more singular uses like “.all”, “.any” and “.race”. These are just different methods for finding an error. All will take an array of “promises” and find any of the errors from the promises and return the promises that resolved. Any will give you the first of the “promises” that resolved. Race is basically just a race to see who completes first regardless of error or not.

Asny and Await are two functions that you generally prefix to another function. Async forces the function to return a promise which allows us to use the Promise “.then”, “.catch” and “.finally” to resolve outside the function. But it doesn’t also mean that we can’t use try and catch as with “await” it allows us to literally wait for a function to resolve and with try and catch we can handle the errors inside of the current function.

Overall this article was very helpful. My intention was to just find an explanation as to what async and await meant, but I ended up with a little crash course on interesting ways of handling errors in JavaScript, as well as clear meanings behind each one.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.