Category Archives: CS-348

CS-348 Quarter 3 Blog Post

For Quarter 3 I’ve chosen this article written by Ting Yu from the The Brink, at Boston University.
https://www.bu.edu/articles/2022/how-copyrights-patents-trademarks-may-stifle-creativity-and-progress/

This article was written in August of 2022. It establishes and idea that law has not been able to keep up with the development of the digital era. This idea, proposed by Jessica Silbey, an expert on constitutional and intellectual property law argues that current law does nothing to advance the public’s creativity and ability to make society better for the collective, instead society lined up today to empower individuals and corporations. In other words, Silbey explains that the idea of individual copyright and trademarking of ones own work is more an empowerment to exclude, making copyright and trademark law seem more on the offensive than defensive.

The reason I decided that this article fit the bill for the semester is of course its relevance to our topics surrounding copyright law and trademarks of our work as programmers and developers. But at the same time I chose it for its interesting take on the implications of copyright law and trademarks on the creativity of the public.

Pulling down from the summary of the article about the empowerment to exclude being used to describe copyright and trademarks, at first it felt like a weird take but the more I thought about it the more it made sense to me. While at face value the idea of copyright and trademarks is to protect the intellectual property of whoever created said property, on the grand scheme of things, especially in a world where you can instantly contact someone from the other side of the planet in an instant it does feel more like a trademark plays the role of a bouncer at the entrance of a club, letting in select people and excluding others. Although the people not being the problem but the intentions of said people as trademarks and copyright determine what one can do with an intellectual property. Something specific that Silbey brings up that to me shows the severe issue with current law is the example about how in days long past, it was usually the inventor of something who would own the patent to said thing, but in todays world its teams of people working all towards a single goal, usually in competition with other companies. Leaving copyright and trademarks usually in the hands of the company the team is operating under depending on contract stipulations. For example the battle between Microsoft, Sony and Nintendo to be the next big innovator in the gaming industry creates hostile work environments powered by profit and quotas. Copyright and trademarks usually held tight with an iron fist by these companies. So while I do need to give this idea more thought I definitely think Silbey has a strong point that shes making for us.

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

Open Source Licencing

Throughout my Computer Science degree, I have contributed to and collaborated on projects that have been posted to Github or GitLab. I have also utilized, downloaded, and sometimes even shared school material that was a Free and Open Source Software (FOSS). In the past, I have never given much thought to my right to the material I accessed, how it was legally allowed to use it, and what practices needed to be in place to protect my own works that I have posted on various version control management sites. In this class we are exploring licenses and copyrights when it comes to any project code that  an individual produces, and the legalities behind the use, alteration and distribution of said works. 

In this video Open Source Licence Types by creator Pro Tech Show dives into open source licenses specifically. This specific area of copyright law when it comes to code is important for me to understand because as someone who will constantly use these sites to host my projects, and as someone who plans to contribute to or create certain HFOSS projects, I need to have a good grasp on how I can go about using others works and sharing my own code. 

This video simplifies the over 100 open source licenses by grouping them into five broad categories based on how they affect the user and the copyright owner. These categories are Public domain, permissive licence, weak copyleft, strong copy left and stronger copy left. The most interesting part of this video was its explanation of the automatic copyright of All rights reserved and how public domain waives all of those rights. I thought this was interesting because many people may be ignorant to the automatic copyright placed on their code that has been posted on github. One may have done so with the intention for it to be shared and collaborated on. There is, however, would require the use of public domain where it would act as an absence of a licence and may be more along the lines of what the author had intended.  It is not only important to know how licensure works as the author, but also as the user. Again, one may assume that they have a Public Domain to access, download, and mutate to code found on git hub, however, I should be taking more care to examine the specific licensing under each project. This would help alleviate any legal issues down the road while also getting me more familiar with the different types of licensing and why types of projects require which licence.

From the blog Anna The Dev by Adrianna Frazier and used with permission of the author. All other rights reserved by the author.

Writing Cleaner Code: Breaking Out of the Student Mindset

https://www.geeksforgeeks.org/blogs/tips-to-write-clean-and-better-code/

Most of our time during our college career and learning how to create working and usable code, there was not really a strong emphasis on how to write “clean code”. Sure, best practices, industry/language standards, and formatting was explained, however, there is another aspect of code legibility and readability that is important to understand for everyone writing code. Our class this semester explores a more indepth view of what industry standards are to be followed and even helps us unlearn some basics (like comments) that we were utilizing in our code.

This article from GeeksforGeeks outlines seven key tips for writing clean, maintainable, and efficient code. It emphasizes that writing good software goes beyond just making it work; the code must be easy to read, understand, and change, as developers spend significantly more time reading code than writing it. The article indicates that adhering to certain practices leads to reliable, scalable software that is easier to debug and maintain, ultimately creating better collaboration among developers 

Some of these practices/principals are ones that we, as students, have already learned to adopt such as using meaningful names for methods and variables, as well as learning how to organize our projects, specifically when it comes to object oriented programming. A new take away that I will be more aware of is how descriptive the names are. I used to think that overly long variable names were “bad practice”, however, for the sake of readability and general understanding of the code, longer, more descriptive variable names may be indicated. 

When it comes to practices that were a new concept for me, the utilization of comments in code was an important one to unlearn. The article notes that code should be self-explanatory through clear syntax and naming. Comments should only be used when absolutely necessary, rather than stating the obvious. Another aspect of clean coding that helped me alter the way I will continue to code is the inclusion explaining how methods should only be used for a single purpose. This method, otherwise called the Single Responsibility Principal, notes that functions and classes should only do one thing and do it well. They should be small and focused, avoiding nested structures or too many arguments  

This article was important because it bridges the gap between “student code” (written for a class assignmentt) and “professional code” (written to be read and maintained by a team). Understanding how to write clean code will help immensely make all of your projects look more professional, as well as help you with technical interviews. Adopting these habits signals to employers that you aren’t just a coder who is able to put together a small school project, but a software engineer who builds sustainable, high-quality products

From the blog Anna The Dev by Adrianna Frazier and used with permission of the author. All other rights reserved by the author.

Blog Post for Quarter 3

November 16th, 2025

Considering how clean code was recently on my mind (mostly due to a recent assignment), I thought it might be interesting to look into. I ended up finding out that there a various style guides (well, a comic from an assignment also showed me that too) and this blog shows some examples. It is nice as a basic overview of some style guides. It most notably noted 3 types of styles that revolve around whitespace usage and brace placement. It compliments what I was learning in class as the class typically focused on things like function and variable names, reducing the amount of nested loops, and the usage of too many parameters. The blog goes over how some styles place braces in a way to make it easier to parse through things like heavily nested loops and such. These both end up telling of ways to increase clarity but in different ways, which is super fascinating.

Interestingly, this led to me to look at my own code. My current code uses the “Allman” style of braces. This was taught to me back in AP Computer Science back in high school. I vaguely remember “Allman” being discussed in class, but I never made the connection between it and how I typed code. I ended up doing it since it was the easiest to read. Well, that and the professor told me that this was the “proper” way to code. (I vaguely remember the thing I did code in also automatically did it for me too.) Since then, I’d sometimes just go around and putting braces in that format. (Perhaps I’m worse off due to this since I overly rely on a style. I’ll need to learn to read other styles soon.)

Overall, I’ve mainly noticed my code is super, super bad. Like, overly bad. So next time I code something, I should do many different things. This blog I picked and the assignments on “clean code” would be a good start honestly. (Unfortunately, as someone who “thinks by doing,” I had a habit of creating copious amounts of technical debt without even realizing it. Then again, I was always the type to prefer redoing things entirely as opposed to looking for minor improvements….) Maybe one day my code will be actually good for once. And thankfully, I’ve got various places to start improving. There’s a long road ahead…. Well, at least that means that I have a lot of ways I can improve; the plateau isn’t here just yet. In fact, it is very far from where I am.

https://iannis.io/blog/the-ultimate-code-style/

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

Better your Coding Standards

For this quarters blog, I decided to write about Coding Standards and chose to read Why You Need Coding Standards by David Mytton. To start off, Mytton talks about what does “proper” code really mean. It is not just any code that works, but rather code that is easy to fix, add to, and update in the future. His blog mentions a common problems that we face today. Many developers start learning code with their own style which only they might understand. Once a project grows and other people join in, different styles will collide and make the code confusing. Mytton explains the frustration of working with messy code and how stressful it is to scroll through long, unclear code with confusing variable names, missing comments, and code without spacing.

There are two main examples that were used to show the difference that coding standards make. Both examples were written in PHP, the first example was messy. There wasn’t spacing, variable names were unclear, no braces around control structures, and long conditions missing parentheses. Although it technically worked, it was definitely hard to read at first. The second example showed the same logic. This time around there was clean formatting, clear variable names, proper indentation, and braces correctly placed. I’ve never used PHP but it was obvious that the second example was much easier to understand.

I selected this blog because recently in class we’ve been working on clean coding and realized how hard it can be to understand code written in different ways. I also wanted to further my understanding of how professionals handle this problem and how they keep projects organized. I think that this blog was able to explain that point in a simple and relatable way for me.

From this blog I learned that coding standards are beyond just “good habits.” It prevents confusion, reduces mistakes, and allows projects to run more smoothly. I also learned that a coding standard is not something that just one person creates and uses for themselves but rather by the whole team. I hope that I am able to fix my poor coding habits and write code that allows others to collaborate with my work. I think before this, I didn’t care much whether somebody would be able to read my code but rather if it was able to run then I was satisfied. My mindset has changed and I want to be more consistent with following coding standards.

From the blog CS@Worcester – wdo by wdo and used with permission of the author. All other rights reserved by the author.

Version Control: Why It Matters in Software Development

Version control is something I’ve used before in classes, but I never fully understood its importance until I read the Atlassian article, “What is Version Control?” (https://www.atlassian.com/git/tutorials/what-is-version-control). I selected this resource because Atlassian explains technical concepts in a way that feels practical and industry-focused, which fits perfectly with what we are learning in CS-348. Since this course emphasizes collaboration, documentation, project organization, and professional tools, I wanted to learn more about how version control actually supports real-world software development.

The article defines version control as the practice of tracking and managing changes to code. What stood out to me is that version control isn’t just for “saving work”, it’s a full system that captures every change, who made it, when it was made, and why. Atlassian highlights how this creates a long-term project history that developers can search through, compare, or revert. This directly connects to our CS-348 topics like software maintenance, project management, documentation standards, and team collaboration, because version control supports all of these practices behind the scenes.

The resource also explains how version control allows teams to work on separate branches, make experimental changes, fix bugs, or build features without interfering with one another. This connected with my experience in this course because when we work on group projects or assignments, version control prevents us from overwriting each other’s work. The article also discusses merge conflicts, and reading about it made me feel better about the moments when I’ve run into conflicts myself. Instead of seeing them as mistakes, the article made me realize they are a normal part of teamwork and software development.

One major takeaway for me was the idea of traceability. Every commit tells a story, not just about the code, but about decisions, goals, and teamwork. This encouraged me to treat commit messages more seriously so that my future teammates (or even future me) can understand the purpose behind changes. The article made me realize that version control isn’t just a technical tool; it is a communication tool. This is something I didn’t appreciate before reading it.

This resource affected how I view my future practice because version control is required in almost every professional software environment. Reading about how teams rely on it to avoid lost work, manage parallel development, and maintain high-quality software helped me understand why CS-348 emphasizes collaboration tools, project organization, and documentation. Going forward, I plan to use branching more intentionally, commit more frequently, and write clearer commit messages. I also want to apply what I learned outside of class by using version control for my personal and club-related tech projects.

Overall, this article helped me connect the technical skills we practice in CS-348 to how real development teams work. It showed me that version control supports not just code, but communication, teamwork, and professionalism — all skills I want to continue developing.

Source

Atlassian. What is version control. Retrieved from https://www.atlassian.com/git/tutorials/what-is-version-control

From the blog CS@Worcester – Circuit Star | Tech & Business Insights by Queenstar Kyere Gyamfi and used with permission of the author. All other rights reserved by the author.

Trending code practices

Article: https://github.blog/news-insights/octoverse/what-986-million-code-pushes-say-about-the-developer-workflow-in-2025/?utm_source=octoverse-cli-announcement&utm_medium=octoverse&utm_campaign=universe25post

GitHub, in this blog post goes over the various trends and changes within pushes and changes made to very high profile repos. These conclusions were made from from 986 million pushes made within the platform which gives a very large sample size which in my opinion would extremely accurately present the current recent trends within the tech industry and open source software. One of the conclusions that GitHub brings up is that it is extremely fast to make changes and build software now than ever before and because of this many developers aren’t just pushing when things are totally done, rather they are leaving somethings within their pushes unready but functional to be iterated and done later rather than having everything within the push completely ready. They equate this trend to the saying “done-ness is temporary”, furthermore pull requests are more concise and simple, and feature flags are often used more and more even if they might be “maybe” feature since developers tend to just shut that feature off and push their changes again without it. The last major point that the author brings forward is that communication has to change to reflect the faster nature of development meaning more communication, faster stand-ups and hiring those who ship faster.

I chose this article due to the fact that the idea that the industry trend of how changes are made fundamentally shifting from large updates to shorter more small and experimental changes is extremely interesting since I’ve noticed this at my work where this is reflected. Often times changes are small and incremental and made to be built off of while maintaining functionality. Even more so my employers policy for pull requests has changed as well which is more simplistic and straight to the point rather than having such detail. But this isn’t without problem in my eyes as like the article states in order to gain missing information from the request communication is key and becomes even more important, especially in cases where there are present issues that require immediate action.

From this I plan to incorporate more things like being easier to reach for communication and communicating faster to better reflect the changes in trends of pushes, so that incase that I adopt the industry trends of smaller pushes to be iterated on with smaller and simpler pull requests, my workflows remain functional and optimized for the most quality while accounting for the changes in trends.

From the blog CS@Worcester – Aidan's Cybersection by Aidan Novia and used with permission of the author. All other rights reserved by the author.

Code Can be Dirty?

Unfortunately, yes

The above code is positively awful to look at, read, try to understand, and generally poor practice. Recently, in this semesters Software Development class, we have moved away from project structures, and into clean code. What makes it clean, why is it important, and related topics.

Why clean?

Clean code provides an easy reading experience for anyone looking at it. This include people later working on something released years ago, as well as the person writing completely new code for the first time. Every example of code can benefit from being clean. Coding cleanly enables readers to understand what the code is doing, and makes it easy to follow mentally. As well as this, clean code can make better code, as spotting mistakes is made easier when you know where everything should be.

What makes code clean?

Clean code is code that is easy to read, understand, and modify because it expresses its intent clearly and avoids unnecessary complexity. It uses meaningful names, small and focused functions, and consistent structure so that another developer can quickly grasp what it does without confusion. Clean code avoids duplication, hides internal details, and keeps responsibilities separated so each block does one thing well. It favors simplicity over cleverness, documents why decisions were made, and is organized in a way that makes future changes safe, predictable, and maintainable.

In the wild

This video is a perfect example of how clean code, and specifically refraining from nesting your code too much, is a good habit to form. The video explains that multiple layers of if statements, loops, and conditional branches make code harder to read, maintain, test, and debug. The creator argues that nesting increases cognitive load because developers must track several scopes at once, and it often signals that a function is trying to do too many things. The video recommends techniques such as using early returns, inverting conditions, and extracting complex inner blocks into smaller, well-named functions so the main “happy path” remains flat and easy to follow. Overall, reducing nesting leads to cleaner, more understandable, and more maintainable code.

I chose this resource as it was a fun video that I found ‘in the wild’ while simply scrolling, and felt that it closely aligned with principles we have been learning in class.

In conjunction with in class learning, I have been swayed to become a ‘never-nester’. I would like to put into practice this behavior, and am excited to maintain clean, readable code in future projects.

This concludes my mandatory blog post of Quarter 3 for the semester.

— Will Crosby

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

Blog 3

          Collaboration Tools

I am Dipesh Bhatta, and I am writing this blog entry for CS-348 Software Process Management for Blog Quarter 3. For this blog, I chose to write about collaboration tools and how they support software process management. My chosen resource is an article titled “What is collaboration?” published by IBM (https://www.ibm.com/topics/collaboration). This article explains what collaboration means, how teams use digital platforms to work together, and why collaboration tools have become essential for modern organizations.

The article defines collaboration as the process of people working together toward shared goals through communication, coordination, and the use of shared tools. IBM describes collaboration tools as digital technologies that support messaging, file sharing, project management, real-time communication, and content creation. These tools help teams stay connected, maintain organization, and share information efficiently. The article emphasizes that digital collaboration is especially important for hybrid and remote teams who rely on virtual workspaces to stay productive and aligned.

I used this resource because collaboration is a central part of software process management, which we focus on in CS-348. Software development requires communication among developers, testers, designers, and project managers, and collaboration tools help streamline this teamwork. By providing shared workspaces and organized communication channels, these tools reduce confusion and make it easier for teams to track progress, share updates, and resolve issues. Understanding how these tools function helps me see the connection between technical teamwork and the structured processes we learn in this course.

This resource helped me realize that collaboration tools are more than just messaging apps—they create clarity and accountability. IBM’s explanation of digital workspaces reminded me of how our CS-348 project groups rely on tools such as shared documents and group chats to stay organized. When team members can access updated files, communicate instantly, and understand their responsibilities, the entire workflow becomes smoother and more efficient.

The article also made me reflect on my own collaboration habits. Keeping documents updated, communicating clearly, checking in with teammates, and using tools responsibly all contribute to better teamwork. I learned that collaboration tools only work effectively when team members engage with them consistently and respectfully. These habits will help me in future group projects, internships, and professional settings where digital teamwork is a daily requirement.

In short, collaboration tools play a major role in software process management. They strengthen communication, improve coordination, and support teamwork—key themes in CS-348. By applying these collaboration practices during Blog Quarter 3, I am building valuable technical and interpersonal skills that will support my future career in the software industry.

From the blog CS@Worcester – dipeshbhattaprofile by Dipesh Bhatta and used with permission of the author. All other rights reserved by the author.

The Clean Code Debate: General Practices vs. Uncle Bob

For this quarter’s blog post, I decided to speak more about the principles of clean code. The resources I discovered when exploring this topic surprised me. I have understood the general concept of writing code that is easy to read, maintain, and understand from the start of my time here at Worcester State University. However, now I have been introduced to the more specific and controversial perspective explained by Robert C. Martin (aka, Uncle Bob). My goal with the resources I chose was to compare Uncle Bob’s approach against how clean code is viewed in more general practices.  

This resource, Clean Code: The Good, the Bad and the Ugly, explores Uncle Bob’s perspective on clean code, while the author identifies components they see to be good, bad, and ugly. The resource “Clean” Code, Horrible Performance, tests Uncle Bob’s clean code components and explains how it impacts performance. Lastly, there are two other resources that give examples of general practices of clean code.

From what I understand, the core idea of clean code is that people read code way more often than they write it, so it is important to prioritize clarity. However, on the other hand, Uncle Bob’s perspective advises for small functions and almost no comments. Some of Uncle Bob’s advice is similar to general clean code practices, but this specific advice leads to some conflicts.

The first two resources showed that sticking too closely to Uncle Bob’s principles can actually lead to decreased performance. This happens due to highly fragmented code (following his principles on small, single-purpose functions), which can be less efficient for the machine to run. The main takeaway from these conflicting views is that Uncle Bob’s ideas are helpful guidelines, but they are not universal rules. It is important to understand the trade-off between absolute readability and optimal performance based on the focus and needs of the project you are working on. 

The advice against using comments genuinely surprised me. In one way, comments are a great way for beginner coders to track the purpose of their code, and to boost their understanding of certain components (i.e., loops, methods, functions, classes, etc.). At least, that is what I often used comments for when practicing coding alone. Now I understand that, when working on a team, those initial comments can quickly become confusing and unhelpful. If a comment is not deleted or updated when the code changes, it becomes misleading. Your code should describe itself using good variables, functions, and method names. If you need a comment to explain what each part of the code does, that may be a sign of poor coding design. 

I had intended to use clean code as I continue practicing coding. However, now I have more tools under my belt to make sure my code is not just digestible for me, but also digestible to someone who may need to read or update my code without me there to explain it.

Main Resources:
“Clean” Code, Horrible Performance. Many programming “best practices” taught today are performance disasters waiting to happen – https://www.computerenhance.com/p/clean-code-horrible-performance

Clean Code: The Good, the Bad and the Ugly – https://gerlacdt.github.io/blog/posts/clean_code/

Messy Code V/S Clean Code in MVC context – https://medium.com/highape-tech/messy-code-v-s-clean-code-in-mvc-context-9ad99079a4f8

What Is Clean Code? A Guide to Principles and Best Practices – https://blog.codacy.com/what-is-clean-code

Additional Resources:
Polymorphism in Java – https://www.geeksforgeeks.org/java/polymorphism-in-java/

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.