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.

Refactoring Code

Refactoring is an important process when maintaining code bases. The goal of refactoring is to change the implementation, definition, and/or the structure of the code without changing pre-existing functionality of the application. Refactoring allows for better extensibility, maintainability, and readability. Refactoring usually results in smaller and simpler code bases, allowing new functionality easier to implement.

When to refactor?

Because refactoring results in simpler code bases, refactoring should be done before adding new features. Working with clean code after refactoring makes the process of adding new functionality easier. For example, if the code base is not extensible, then adding new functionality might break the code leading to more work to fix the problem. Refactoring should also be done before code reviews or before addressing bugs.

What code needs refactoring?

Code smells can be defined as structures in the code that indicate violations of fundamental design principles and negatively impact design quality. Code smells can be used to identify what needs to be refactored. There are over 70 refactoring techniques that help identify problems and provide a known solution. Some techniques are the Extract Method, Replacing Temp with Query, and Encapsulation of a Field.

Refactoring techniques

Extract Method

The Extract Method can be used when code can be grouped together. For example, there is a class called ‘Student’ that has two print statements that prints student details such as name and year. Refactoring would include grouping the two print statements together into its own function. This is helpful because if you wanted to add more details to be printed, you only have to add one line to the function.

Replace Temp with Query

Temp refers to a temporary variable that holds a value of an expression to be used later in the code. This technique replaces the temp variable with a query method that returns the result of an expression. For example, there is a variable where ‘basePrice = quantity * costPerItem’. The variable can be represented as a new method called ‘basePrice()’ that returns the expression, ‘quantity * costPerItem’. If the temp variable is used among multiple classes, having a common method would more manageable.

Encapsulate Field

Encapsulating a field involves using methods that read and write data rather than accessing data directly. When accessing variables directly, they are often set to public which allows the data to be modified without a way to validate the change. Getter and Setter methods should be used to access class variables instead because the access level for the variables can be set to private, meaning the data itself cannot be accessed unless using the access methods. Using access methods provides a way to validate changes.

Reflection

This resource was used because it was clear and concise, making the content easy to understand. The article also included code examples of the techniques which improved comprehension. Before reading, I was unaware of some of the techniques listed which will be helpful when refactoring in the future.

Resources:

https://www.geeksforgeeks.org/refactoring-introduction-and-its-techniques/#

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

Ever struggle to read another developer’s code? Code should be easy to follow along with, especially for a reader entirely new to the codebase. However, sometimes developers write “spaghetti code”, with random variables or methods mixed together in a non-understandable manner. 

Gary Espinosa of Reflectoring.io believes that clean code is the best code, and it’s super important for companies and coworkers. He lists suggestions such as variable names being descriptive, methods shortened, code broken up, etc. Let’s dive into what he suggests.

Espinosa discusses the huge importance of clean code, and how it can make or break a codebase. Not only is code the flesh and blood of a program, but it is also a form of communication between collaborating developers. It helps enable easy understanding of code and editability without errors. Companies who need to ensure their code is clean often spend time and resources just making it easy to comprehend.

Clean code should be readable; this involves grouping similar functions and classes together, similar variables, etc. The document should flow like an “engaging narrative from top to bottom” (Espinosa). If possible, one idea per line and one action per statement is key.

You should also be able to keep your code consistent. There must be a standard for writing code, variables, and methods. Examples of this would be using camelCase for all your variable and method names, using specific indentation rules, and more. A unifying language reduces differences.

One should strive for simplicity, but with descriptive language as well. Variables, methods, and classes should have meaningful names that describe the point of themselves easily. For example, you shouldn’t use a name like “x1” or “yY” as they don’t provide the reader any insight as to what they’re for.  

I selected this resource because it lines up with what we’re currently learning, and it is a key importance to being a software developer in the industry. If you want to have your pull requests approved, write clean, understandable code. This topic intrigued me because it’s quite simple but I wasn’t sure if there were any specific industry standards for clean code. There are definitely certain uniforms industry-wide, but I’m sure that it depends from company to company.

Espinosa’s article was informative, and explained what’s important and why about clean code. It’s useful to those new to programming, or those who are experienced in coding but just entering the professional industry.

I learned how important clean code actually is, not only to the programmer but to their coworkers and the company as a whole. Alongside this, the article taught me how to effectively organize and write code in a clean and understandable manner. This led to an increase in my confidence in my ability to clean up my code. I want to apply this knowledge to my future jobs and perhaps go back and clean up my old projects to make them easier to comprehend.

Article: https://reflectoring.io/clean-code/

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.