In this blog, I will go over the code “smells” pertaining to the Javascript language. For this topic, I picked a specific blog post called “Javascript Code Smells: 7 to Watch out For” written by .NET software developer Carlos Schults. It delves into this topic with lots of general details that explain some bad coding practice that can lead to your code having many problems. One of the main points that the blog emphasized was that long code alone was not a bad thing rather, the difficulty of reading lines of code that became too complex to handle makes these coding “smells” important to look back on when writing code.

The reason why I picked this topic is because I have had trouble with Javascript that I had never experienced before with other programming languages such as Java or C. One of the biggest factors that made it harder to understanding Javascript was its different and more difficult use of syntax. One of the coding “smells” the blog goes over was the difference in using the equality operand in Javascript compared to Java. Since I have been more involved with other programming languages such as Java than Javascript, learning the different coding structures of Javascript was going to take a while for me to grasp, especially since coding software such as OpenAPI uses Javascript to define its data and endpoints.

My main takeaway after reading this blog was that I should continue to further explore Javascript, while also maintaining the knowledge that I currently have when it comes to organizing the code I write. Reading this article about Javascript coding “smells” was very reassuring since I may have to find a similar reference to keep my coding consistent even after learning Javascript and not let it worsen with more and more complex functions for future coding. Having already had lots of experience with other programming languages in the past, I can use what I have learned from this blog and make better use of Javascript moving forward. 

Reference: https://www.testim.io/blog/javascript-code-smells/

From the blog CS@Worcester – Elias' Blog by Elias Boone and used with permission of the author. All other rights reserved by the author.

Before taking this class, I didn’t know of any guidelines for writing code. Clean code is a guideline with an objective to make code easier to understand, maintain, and read. By following its principles, a developer makes projects more likely to succeed in the long term. Learning this, I thought that I should try to implement this in all I code I make, and am still trying to make clean code practices common in my code. However, in a blog post: “Goodbye, Clean Code” by Dan Abramov, he says to “let clean code guide you, then let it go”. This was interesting, since wouldn’t having clean code all the time be nice to have for understanding the code you write? Dan during the time he recalls in the post thought so too.

In this post, Dan recalls a time when he was working on a project and checking his colleague’s code they had just turned in. The code had tons of repetitive code and math that would take a second to process. Bothered by this, he fixed it to look cleaner, removing the repetitiveness and making it so there could be changes in one spot rather than multiple methods. This resulted in a request that he reverts the changes he made from his boss, which he reluctantly agreed to do. Looking back at this event, the author says it took years to understand his boss was right. Calling clean code a phase of a coder’s life and explaining that chasing that guideline was forgetting about the human aspect of coding. Firstly, he changed his colleague’s code without discussion, which was a terrible decision when working in a team where they needed to collaborate. Secondly, he realized later that the changes he made would have impacted the project severely and added complications if he had kept them.

This blog post was not saying there was a problem with clean code itself, but how people treat clean code as an absolute guideline like the author did in the past. This post helped me understand chasing clean code is more of a detriment to yourself and others on your team and to not get too obsessed with it. Getting hung up on this aspect makes you lose sight of your project and team’s goals in mind. I think that people should keep writing clean code but not lose themselves to chasing a standard in a way that makes writing that code meaningless. While I haven’t experienced this, I can sort of understand it as how I was trying to implement these principles in my code after learning of them.

References: https://overreacted.io/goodbye-clean-code/

From the blog CS@WORCESTER – Leon's Blog by llai194 and used with permission of the author. All other rights reserved by the author.

Hey Coders! Feeling lost in a maze of confusing code? Tired of code messes and bug hunts?

Today, let’s dive into the exciting world of open-source scientific software. If you’re like me and tired of dealing with confusing code and chasing bugs, don’t worry! The article “Ten simple rules on writing clean and reliable open-source scientific software” by Hunter-Zinck et al. (2023) is here to show us the way to clean, reliable, and easy-to-handle code that benefits everyone.

Why This Article Rocks

This article stood out because it tackles two key issues: making code user-friendly and emphasizing the importance of open-source software. Plus, it simplifies complex software development into 10 easy-to-follow rules.

The 10 Golden Rules

The article outlines 10 key principles for writing clean and reliable open-source scientific software. Here’s a quick rundown, with a dash of my own insights:

1. Modularize: Break down your code into smaller, independent units. This makes it easier to understand, test, and maintain. Think of it like building with Legos – you can easily swap or add new pieces without affecting the whole structure.
2. Document everything: Write clear and concise comments explaining your code. Imagine someone completely new to your project needs to understand it – would your comments guide them through the jungle?
3. Use descriptive names: Don’t be cryptic! Choose variable and function names that accurately reflect their purpose. Think of them as road signs – they should tell you exactly where you’re going.
4. Test relentlessly: Write unit tests to catch errors early and often. These are like little detectives, constantly scrutinizing your code for any suspicious activity.
5. Version control is your friend: Use tools like Git to track changes and revert to previous versions if needed. It’s like having a magic rewind button for your code!
6. Automate your tasks: Write scripts to automate repetitive tasks. This frees you up to focus on the bigger picture and avoid tedious manual work.
7. Embrace continuous integration: Set up systems that automatically test and build your code when changes are made. This helps to identify problems early and prevent them from snowballing.
8. Get feedback: Share your code with others and ask for their feedback. This can be like having a team of extra eyes, spotting errors and suggesting improvements you might miss.
9. Contribute to the community: If you’re using existing open-source software, consider contributing back by fixing bugs or adding features. Remember, it’s a two-way street!
10. Stay up-to-date: Keep your codebase and dependencies up-to-date with the latest versions to ensure compatibility and security. Think of it like keeping your operating system updated – it’s essential for smooth sailing.

Learning and Beyond

This article has been a game-changer, offering a clear roadmap for writing clean and reliable open-source scientific software. Looking forward, my plan is to further refine my skills in writing clean and reliable code and actively contribute to the open-source community.

P.S. For more detailed explanations and examples of each rule, check out the original article here.

From the blog CS@Worcester – Site Title by Iman Kondakciu and used with permission of the author. All other rights reserved by the author.

In the engaging podcast-style video, “Clean Code: Horrible Performance,” https://www.youtube.com/watch?v=OtozASk68Os&t=1944s two seasoned developers share insights over 47 minutes on the delicate balance between clean coding and system performance.

The developers initially champion the virtues of clean code—emphasizing readability, maintainability, and collaborative benefits. However, the conversation takes an interesting turn as they delve into the paradox that clean code might lead to suboptimal performance.

Real-world examples illustrate scenarios where an excessive focus on code cleanliness can unintentionally hamper efficiency. The developers caution against over-optimization and stress the importance of a balanced approach.

Practical insights emerge as the duo offers strategies for identifying bottlenecks and optimizing critical code sections without sacrificing readability. They acknowledge the evolving nature of software development, where the pursuit of clean code intersects with the demand for high-performance systems.

In conclusion, “Clean Code: Horrible Performance” serves as a valuable guide for developers seeking to strike the right balance between clean coding principles and performance optimization. The developers’ experiences provide practical wisdom for navigating the complexities of modern software development without compromising code aesthetics or system efficiency.

From the blog CS@Worcester – Dose Of Dev by msavice and used with permission of the author. All other rights reserved by the author.

This week’s blog post I decided to research more about linting for non-inclusive language. The medium I selected is a blog post by Michael Bachand, an engineer at Airbnb. “Building an Inclusive Codebase” dives into the techniques engineers at Airbnb are taking to make their work environment more inclusive for everyone. In order to create a more inclusive platform, the development team must also be inclusive. To start, the team has increased the diversity in their teams to accommodate every demographic. Bachand emphasizes that building a diverse team will help empower both Airbnb’s hosts and guests. Inclusivity goes beyond forming a diverse team however.

The team at Airbnb discovered an issue with non-inclusive language in their codebase. After working with employees affected by these terms, the team presented a proposal to the Chief Technology Officer of Airbnb and got the approval to refactor the code to be more inclusive. Michael Bachand stresses that “acknowledgement and resourcing from the highest levels of management legitimized this effort”. The support from management and the CTO prioritizing the task produced a healthier working culture across all teams.

Airbnb’s development team broke down this problem into two key parts: preventing the use of this language and eliminating the existing language. One essential tool that was utilized was the woke linter which checked each pole request for non-inclusive terminology and suggested alternative terms to promote belonging. The team now had a proper tool to use, however, they didn’t send the tool to every developer immediately. The team took a unique approach by slowly distributing the tool to expert developers. These developers decided which directories the linter should access and which should be excluded.

Before our in-class activity on this topic, I never thought about how my sentences might unintentionally offend or upset someone. This topic has opened my eyes to how crucial having a linter tool is. Many of these non-inclusive terms sound offensive without the right context which is why every developer should utilize a linter of sort. Reflecting on the problem addressed by Airbnb, having the support from the CTO is reassuring to know that your work is valued by the company. I believe all companies should strive to create a sense of belonging in their work environment, no matter how big or small. I can confidently say that the information I learned today will stick with me for the rest of my career.

Blog Post: https://medium.com/airbnb-engineering/building-an-inclusive-codebase-bbaa2315e5b8

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

Inversion of control is a software principle that asserts a program can benefit in terms of testability and usability if the management of an application’s flow is transferred to a different part of the program. I.O.C’s framework takes the management of an application’s implementation away from the developer. When interactions require custom business logic, the I.O.C framework will use the code provided by the developer. This is the “inversion” point of the inversion of control design principle. The most common application for Inversion of control is Java servers faces. I.O.C frameworks implement low-level and problem-prone activities, it allows the developer to focus on custom business logic instead of tedious tasks.  The one thing about inversion of control is that it can confuse what qualifies as an I.O.C and what doesn’t. Some examples of inversion of control are event-based user interfaces, shared cache, and comprehension framework—the range of development changes that qualify as I.O.C contributes to the term. I.O.C is a principle, not a design pattern- the implementation depends on the developer. I.O.C just provides high-level guidelines. Inversion of control and dependency injection are usually used interchangeably. Dependency injection is one implementation of I.O.C., it’s a technique that allows objects to be separated from other objects that they depend on.

Dependency injection suggests that instead of making an instance of class b into class a using the new operation, the object of class b should be placed into class a using one of these methods constructor injection, setter injection, and interface injection. Another example of implementation in I.O.C is the spring framework. That contains instances and manages the lifecycle of the objects in the program. The user in the configuration file provides information that relates to what objects and dependencies are used by the application like Java code. The benefits of Inversion of control are that it makes the application easier to test and maintain, reduces the amount of application code, and decreases the coupling between classes. Inversion of control helps make your code more readable because of the absence of some components. At the end of the day, I.O.C is a design pattern that is very useful for software development and lets us know when action needs to be taken when something happens in our system.

https://www.theserverside.com/definition/inversion-of-control-IoC

https://www.educative.io/answers/what-is-inversion-of-control

From the blog CS@Worcester – Kaylene Noel's Blog by Kaylene Noel and used with permission of the author. All other rights reserved by the author.

Inversion of control is a software principle that asserts a program can benefit in terms of testability and usability if the management of an application’s flow is transferred to a different part of the program. I.O.C’s framework takes the management of an application’s implementation away from the developer. When there are interactions that require custom business logic, the I.O.C framework will use the code provided by the developer. This is the “inversion” point of the inversion of control design principle. The most common application for Inversion of control is Java servers faces. I.O.C frameworks implement low-level and problem-prone activities, it allows the developer to focus on custom business logic instead of tedious tasks.  The one thing about inversion of control is that it can confuse what qualifies as an I.O.C and what doesn’t. Some examples of inversion of control are the use of event-based user interfaces, the use of shared cache, and the use of comprehension framework. The range of development changes that qualify as I.O.C contributes to the term. I.O.C is a principle, not a design pattern- the implementation depends on the developer. I.O.C just provides high-level guidelines. Inversion of control and dependency injection are usually used interchangeably. Dependency injection is one implementation of I.O.C., it’s a technique that allows objects to be separated from other objects that they depend on.

Dependency injection suggests that instead of making an instance of class b into class a using the new operation, the object of class b should be placed into class a using one of these methods constructor injection, setter injection, and interface injection. Another example of implementation in I.O.C is the spring framework. That contains instances and manages the lifecycle of the objects in the program. The user in the configuration file provides information that relates to what objects and dependencies are used by the application like Java code. The benefits of Inversion of control are that it makes the application easier to test and maintain, reduces the amount of application code, and also decreases the coupling between classes.

https://www.theserverside.com/definition/inversion-of-control-IoC

https://www.educative.io/answers/what-is-inversion-of-control

From the blog CS@Worcester – Kaylene Noel's Blog by Kaylene Noel and used with permission of the author. All other rights reserved by the author.