Now I know what everyone is thinking, ‘You lied in your last blog.’ Yes, I did, and guess what? This is my blog, so that’s okay. You see, I could not pass up on this beautiful opportunity to kill two birds with one stone. As you may remember from my last blog, I complained about how hard it was to come up with topic ideas for CS-343. Well, well, if by some miracle I read that if topics intertwine between your two classes (343/348), we could count one blog for both classes (shoutout Prof Wurst :)).

Enough yapping, clean code time. I believe it was only a year ago when I first started taking coding seriously, and I can recall how awful my code looked. It worked… but if you wanted to debug, you had to pray before opening it. We are talking about one-function programs, with no formatting and variable names that would drive any professor mad. I quickly realized how important clean code was after watching some YouTube videos and seeing how much easier debugging was if your code had a good flow and was properly formatted. This is where I stopped when it came to clean code, unknowing that there were 100+ other factors that all combine to make clean code.

While exploring LinkedIn, I came across this article by Oleabhiele Donald titled ‘Benefits of Clean Code In Your Application Development.’ I gave this a full read and was really surprised about all the little ways I could make my code even better than it already was. Now I 1000% recommend giving it a full read, but I’m going to talk about some of the techniques that were mentioned that I didn’t know at the time or found most beneficial to me.

Use comments sparingly:

• Limit the use of comments to when necessary, ensuring clarity and conciseness. Overusing comments can clutter the code, making it harder to read. Aim for clear and concise comments that add value.

Write small, focused methods:

• Break down larger methods into smaller, focused ones, each with a single responsibility. This approach improves code understanding and facilitates easier modification.

Use unit testing:

• Incorporate unit testing practices to verify code functionality and prevent the introduction of errors. Well-designed unit tests contribute to clean and reliable code.

Avoid duplication:

• Identify and eliminate code duplication by utilizing methods, classes, and inheritance. Reducing duplication enhances code maintainability and modifiability.

These techniques stood out to me mostly because they were things I just didn’t think about. I love to keep a list on my desktop notepad that always reminds me of some of the key steps to clean code.

Why Clean Code? This a very simple answer thanks to the article, clean code is important enhances readability, making it easier for developers to understand, maintain, and collaborate on software projects. It also improves efficiency, scalability, and reduces the likelihood of introducing bugs, ultimately leading to more reliable software and a happier programmer.

Source: https://www.linkedin.com/pulse/benefits-clean-code-your-application-development-daniel-donald/

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

SOLID is an acronym that stands for the 5 different principles that help write high-quality, maintainable, and scalable code. These include Single Responsibility Principle (SRP), Open-Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP) and Dependency Inversion Principle (DIP). Each provides their own benefits and work in tandem together when designing a program.

SRP states that a class should only have one responsibility, meaning only one reason to change. This helps prevent a class from having too many responsibilities that can affect each other when one is changed. Following SRP ensures that the code will be easier to comprehend and prone to fewer errors. However, it is harder than it sounds to fulfill this principle. The quickest solution to adding a new method or functionality would be to add it to existing code, but this could lead to trouble down the road when trying to maintain the code.

OCP states that software classes, modules, functions, etc. should be open for extension but closed for modification. This is essential because it allows entities to be extended without modification so that developers can add new functionality without risking the chance of breaking the code. Adding an additional level of abstraction with the use of interfaces help design the program to provide loose coupling.

LSP states that any instance of a derived class should be substitutable for an instance of its base class without affecting the program in a harmful way. The importance of this principle revolves around the ability to ensure the behavior of the program remains consistent and predictable. Unfortunately, there is no easy way to enforce this principle, so the user must add their own test cases for the objects of each subclass to ensure that the code does not significantly change the functionality.

ISP focuses on designing interfaces that are specific to a user’s needs. Instead of creating a large interface that covers all methods, it is more beneficial to split up the methods across smaller, more focused interfaces that are less coupled. For example, having too many methods in an interface can sometimes cause issues in the code, so separating the methods into individual interfaces that can be implemented by a certain class.

DIP states that high-level modules should not depend on lower-level modules but should depend on abstractions. This approach aims to reduce coupling between modules, increase modularity, and make the code easier to maintain, test, and extend. An important thing to note is that both high-level and low-level modules depend on abstractions. Dependency Inversion utilizes the SOLID principles which in turn leads to a more refined and maintainable code.

This is related to the class subject in many ways because it works as a guideline to write the most convenient code for programmers to maintain. Testing the aforementioned code is a simpler process when abiding to the SOLID principles as well. It also allows for easy scalability, making it essential for large code sets that evolve and become more complex over time.

SOLID Design Principles: The Single Responsibility Explained (stackify.com)

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

When I first started coding in AP Computer Science, I found it fun. It was like solving a puzzle, a difficult one at first, but it slowly made sense. One thing I struggled with was clean code. I remember vaguely writing code that was disgustingly dirty, as in unorganized, unreadable to others, and all around messed up. I’m surprised I was able to get something to work in those conditions. I soon realized that clean code would be a game changer, as I would be able to read it clearly, and follow along easily.

Clean code consists of some points, having good and descriptive method and variable names, appropriate spacing between different lines of code, and good sectioning are some examples. Ultimately, these can go further based on context. Some variables may not need overly descriptive names if there’s enough context to imply what it is used for. 

In this blog post, Karolina Tóth interviews Robert C. Martin, or Uncle Bob, on his way of building quality code. The post is fairly lengthy but it has very good tips. Uncle Bob talks about what clean code is, its benefits, how not using clean code can negatively affect you, and many more. One tip he gives is keeping your functions as small as possible, because once they start to get large, the method starts to become confusing. By not writing clean code, you slow everything down. On a team, it’s difficult to work together if someone’s code looks like a 5 year old wrote it. By writing clean code, the team can work effectively and efficiently, ensuring quality code. 

I think this is a good post, Uncle Bob has good information, not only on clean code, but also boosting team morale and how to ease into using clean code. His knowledge in teamwork comes from his own experience and mistakes, which I like. Someone has to make mistakes for others to learn, and fortunately, Uncle Bob has done just that.

Clean code is important, whether you work in a team, or alone. It’s good practice to do so. When I first started, it was sloppy code. But now, I can’t stand seeing unorganized code. Even after we had learned clean code in class, I realized that mine wasn’t exactly perfect either. I liked my variable names to be descriptive, but short, and I made the short part priority because I’m lazy. But after reading this post, I understood that it’s not always good to keep them like that, having overly descriptive names can be beneficial, but when they have to be. I like things to be clean, and orderly, and neat, and whatnot, so I’ll be sure to refer back to this post, and the rest of Uncle Bob’s resources later down the line.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

In the dynamic realm of software development, a beacon of practical wisdom guides developers through the maze of endless possibilities: YAGNI, an acronym for “You Ain’t Gonna Need It.” This principle advocates a minimalist approach, urging developers to focus on the essential and resist the allure of unnecessary features that might never see the light of day.

YAGNI encourages a “just-in-time” mindset, directing development efforts exclusively toward existing requirements. The core idea is simple: avoid building features or solutions prematurely. Unnecessary additions can introduce complexity, extend development time, and potentially introduce bugs. By embracing YAGNI, developers keep a sharp focus on immediate goals, prevent over-engineering, and maintain a lean and efficient codebase. This not only enhances the development process but also simplifies debugging and ensures a clean and manageable codebase.

Why This Resource?

This extended version builds upon the insights of my previous blog, providing a deeper exploration of the YAGNI principle. The selected resources, Martin Fowler’s YAGNI and C2 Wiki’s YouArentGonnaNeedIt, stood out as foundational pieces providing deep insights into the YAGNI principle. Martin Fowler, a prominent figure in software development, and the collaborative wisdom of the C2 Wiki community added credibility to the understanding of YAGNI.

Insights and Personal Reflection

Delving into Martin Fowler’s exploration of YAGNI, I found a nuanced perspective on the principle. Fowler emphasized the importance of simplicity and addressed the misconception that YAGNI means avoiding all forms of future-proofing. It struck a chord with my experiences, providing a more refined view of when and how to apply YAGNI.

The C2 Wiki, on the other hand, offered a historical context and a communal understanding of YAGNI. Reading through the anecdotes and shared experiences of developers reinforced the practicality and effectiveness of the principle. It resonated with me on a personal level, as I could relate to the scenarios described by fellow developers.

Application in Future Practice

Armed with a deeper understanding from these resources, I anticipate applying the YAGNI principle judiciously in my future projects. Fowler’s insights clarified the delicate balance between avoiding premature features and wisely preparing for potential future needs. The collective wisdom from the C2 Wiki provided a broader perspective, showcasing the universality of the challenges YAGNI addresses.

Conclusion

This extended exploration, building upon the foundation laid in the previous blog, solidifies my grasp of the YAGNI principle. The combination of Martin Fowler’s authoritative voice and the collective wisdom of the C2 Wiki community has enriched my comprehension. I am confident that this refined understanding will significantly influence my coding practices, contributing to the creation of more efficient, maintainable, and adaptive software solutions.

You can read more about YAGNI at:

• YAGNI: You Aren’t Gonna Need It – Martin Fowler
• YouArentGonnaNeedIt – C2 Wiki

From the blog CS-343 – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

One of the most important aspects of code is to make sure that others who work on or are reading your code can understand what is happening. In class, we have been discussing clean code and improving readability which is where the correlation comes into play which is what inspired me to read further onto the fine details of what entails good code documentation. The blog post I chose for this week’s post was “Shaping better software: The benefits of effective code documentation” by Anabelle Zaluski. The goal of the post was to discuss the importance of having good code documentation and what qualifies as good code documentation.

The blog post starts off with explaining why code documentation is very important as it is like a map for your code. Good code documentation is what allows people to navigate your code effectively and efficiently. According to Zaluski the main information that should be included to qualify as effective code documentation is: “Dos and Don’ts, Clear explanations of each aspect of the application, Illustrative images, including sequence and entity relationship diagrams, and API documentation explaining each class, method, and return value”. She then explained the different types of code documentation as internal, external, low-level, walk through and high-level. With the end of the post explaining the benefits and challenges of implementing good code documentation into your team’s work routine. Some of the benefits included improving team collaboration, supporting maintenance and bug fixing, as well as increasing organizational growth. However, some of the challenges mentioned were staying up to date, managing documentation of non-linear code, and knowing how to document things for various knowledge levels.

I chose this blog post since we have been discussing what clean code is and why we should be using it in our own work. Due to that I thought this blog post was perfect to allow me to connect other ways I should be working to improve the quality of my work. To me this blog post was a very useful lesson reinforcing key points about documentation as well as teaching me aspects that I was unaware of. As we are learning more and more about how to structure our code to improve the quality as well as the efficiency of our team based code. From this blog, I feel like I will be able to implement the strategies and qualities mentioned for good code documentation to improve how I document my work in the future.

https://www.notion.so/blog/code-documentation

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

Overview

It is very important for every software developer to be able to write clean, understandable, and maintainable code. Writing clean code will not only be confusing to the user, but it can also confuse the author who is still in the process of writing the code. In my opinion, organization and neatness is the foundation of reaching success in anything. The two main components that will decide if your code is clean are the naming of variables and how functions are written. An article I read by Yiğit Kemal Erinç explained this well.

Naming Variables

We give variables names because they are far easier to remember than its memory address, which is a mixture of numbers and letters. Names give you more information about the variable as well. Someone using your code would likely have a tough time understanding a variable just by the memory address.

The name of a variable should be meaningful. If you need to attach a comment next to the variable to explain its purpose, then you need to rename the variable. The name should already tell you the variable’s purpose and why it exists, and how it should be used. If a name requires a comment, it does not reveal its intent. 

When naming variables, it’s important to avoid disinformation. For example, a variable that has the suffix “-list”  should be a linked list. For a variable to have the “-list” suffix and not be a linked list would be disinformation and lead to confusion.

Writing Functions

There are plenty of tips for how to design clean, easy-to-follow functions. One very helpful tip is to keep the functions small. Functions should be nowhere near 20 lines long. The longer a function gets, the more likely it is to do multiple things and have side effects. From the article, the most important concept was to make sure that your functions only do one thing. If your function only does one thing, it is guaranteed that your function will be small. A good way to check if your function is doing multiple things is if you can create another function out of it. As for side effects, unintended consequences of your code. Side effects can involve changing passed parameters and global variables, which will leave your code tangled up.

Conclusion

Clean coding is not a skill that you learn overnight. Like anything else you want to be good at, it takes practice and repetition. When you write code, make a habit of the clean code principles, so it becomes second nature.

Source

https://www.freecodecamp.org/news/clean-coding-for-beginners/

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

In the dynamic world of web design, managing projects efficiently is a constant challenge, and collaboration between team members is key to a successful management of projects. Without a strong version control system, things can quickly get out of control, leading to lost files, overwrites, and the dreaded conflicts between front-end templates and back-end functionality. In this blog post, we analyze the insights presented in the article “Introduction to Git for Web Designers” explore the benefits of version control and take a deep dive into the world of Git, an open-source version control system that has become a staple for web developers and designers alike.

The Power of Version Control

Version control, also known as Revision Control or Source Control Management, is a game-changer for web designers working in collaborative environments. The basic concept involves a central repository for project files, allowing team members to check out, make changes, and commit them back to the repository. This systematic approach tracks changes, timestamps them, and provides a clear history of revisions. The advantages include preventing file overwrites, maintaining a common repository, facilitating simultaneous collaboration, and offering the ability to revert to previous versions if needed.

The Developers’ Current Struggle

Before diving into Git, many developers manage their files using a crude version control system. Picture a folder filled with various versions of PSDs and other large binary files, an approach that works for static designs but falls short when managing the source code for a dynamic website.

Git: Your Ultimate Version Control Companion

Among the various version control systems available, Git stands out as a powerful, distributed version control system originally created by Linus Torvalds for Linux kernel development. Unlike its predecessors, Git ensures that every user has a complete copy of the repository data stored locally. This distributed nature brings several advantages, including offline work capabilities, resilience against a single point of failure, and faster processes.

The Learning Curve

While Git has a slightly steeper learning curve compared to some alternatives, the benefits far outweigh the initial challenges. Installing Git may seem daunting at first, but there are many online resources and guides to assist users on different operating systems.

Getting Started with Git

Once Git is installed, transitioning an existing folder into a Git repository is a straightforward process. Through simple commands in the terminal or command prompt, users can initialize a directory, add files, and commit changes. Visual tools like Git GUI, GitX, and TextMate with a Git bundle provide user-friendly interfaces for those less inclined towards the command line.

A Peek into a Sample Git Workflow

A web designer’s daily interaction with Git involves checking for the latest changes, making edits, committing changes locally, and pushing them to the master repository. Tools like GitX and TextMate’s Git bundle offer efficient ways to organize commits and visualize changes.

Learn More and Level Up

For those eager to delve deeper into Git, a variety of resources are available. Git cheat sheets, tutorials, and online guides can help developers become proficient in this essential tool. Embracing version control is not just about file management, it represents a fundamental change leading to effective teamwork and project triumph.

Conclusion

In the fast-paced world of web design, mastering version control is an essential skill. Mastering version control with Git isn’t just about files – it’s about smooth teamwork and awesome projects. Git gives you the tools to collaborate without the chaos. So, dive in, make friends with Git, and enjoy a design journey with fewer headaches.

Reflecting on the blog:

In summary, the article “Introduction to Git for Web Designers” stands as a guide for design professionals maneuvering the detailed world of version control. With clear explanations, it unravels the seemingly complex realm of version control, emphasizing Git as a crucial tool for bringing organization and collaboration to the field of web design.

References

https://www.webdesignerdepot.com/2009/03/intro-to-git-for-web-designers/#more-7224

From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

When our class was being introduced to GitLab, and how to post topics on an issue board there were a couple of terms present within the menus that we didn’t go over in class. These terms are story, epic, and initiative, all of which relate to each other. Conveniently all of these terms build off the formers’ progress, and can easily be slotted into a DevOps-esque working environment.

The first of these terms, a story, is what we are most familiar with as it’s another term for an item selected from the Sprint Backlog. A story is a unit of work that can be completed in a one to two-week span. These often come from user feedback, meaning that the product has seen some use outside of development, however stories can originate internally (just like items on a Sprint Backlog). Stories are supposed to be smaller so developers can take multiple during one sprint with the goal being a handful of stories contributing to an epic.

The next term, an epic, is composed of several stories and aims to explain something larger during the development cycle. For example, if you are developing an app that doesn’t have features such as colorblind compatibility, text zoom, and a narrator, then each of these additions could be a story (can be an epic itself depending on the workload). The epic here would be ‘Improving accessibility’.

The final term, an initiative, similar to the former is composed of the prior terms, in this case an initiative is formed of several epics. These run for a minimum of half a year and can continue well past one. These serve to highlight the direction in which the project is aiming to head towards. Continuing the example from the previous term, if we add epics such as ‘Marketing towards non-likely users’ and ‘sign-on bonuses’ it can fit into an initiative that may be ‘increasing user engagement’.

For the purpose of this class, stories are going to be what we encounter the most, with maybe an epic or two depending on the scale of a project. What I’m curious about is whether these terms can be applied to the capstone project course. That course specifically will focus on working on a much larger scale project, so keeping track of tasks via stories/epics/and initiatives could prove to be effective. A reason why I understand these terms not being taught within the course is due to scaling. We focus on learning agile development as it is much more flexible for both smaller and larger projects, meanwhile an epic-based development process may only see great benefits from working on a larger project.

-AG

Source:

https://www.atlassian.com/agile/project-management/epics-stories-themes

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.

While searching for a first topic to write about, the question in mind I wanted to answer was “What is the formal definition of the processes we have been following” and “How does it all relate to what we’ve learned”. This question was answered by the following article which introduced me to the term DevOps, which is abbreviated for Development and Operations.

The following article grants a brief definition of what DevOps is, but most importantly shows the core values that all tie this subject together. Most of these core values we went over in great detail within our class, such as Continuous Integration and Deployment, while others were completely new to me such as Infrastructure As Code (IaC). This simply put focuses on how we interact with Infrastructure and looking at areas in which it can increase efficiency through automation.

Beyond showing the core values, this article speaks on the best ways these are applied. Some of these topics are implied such as collaboration through Agile Development and Continuous Integration and Development, but there was one I did want more clarity on and that is automation. Fundamentally I understand that teams can use automation to increase efficiency, however it does seem counterintuitive in an environment that promotes teamwork. On one hand, you can increase efficiency by letting automation ‘do its thing’ with little supervision, but that may create future errors. These errors and subsequent corrections will reduce efficiency later in development. If you allocate one (or more people) to frequently supervise the automated process, then there’s less of a risk of something going wrong, but you lose the efficiency that one (or more) people could’ve provided. By arguing this I’m not stating that automation does not have a place within DevOps, but that it may be a dangerous inclusion if not accounted for correctly.

Overall I found this article useful in expanding my knowledge of what we’ve learned throughout the semester, the visual(s) provided showing each component of the DevOps processes did help too. One thing that I would suggest for future semesters is maybe looking into how automation can be integrated into DevOps and appending it to your current lectures/activities? I think the curriculum for CS-348 is very good as of now, but adding a unit about automation could maybe help answer some of the questions I asked and potentially could help future students be ready for what they may see in the workforce (beyond college). Lastly, the source in which I retrieved this information seems to be a post on LinkedIn by a company named Quality Matrix Group, so there seems to be plenty of credible information within the post.

(Bonus points for them being based locally in Westborough MA!)

-AG

Source:

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.