Category Archives: CS-348

Using environments to develop software

Different environments in software development, outlining the roles of Development, Testing, Staging, and Production environments.

So you want to get started with developing a piece of software but aren’t quite sure where exactly you are meant to do that. Well luckily for us we have environments created specifically for developing software.

Introduction to development environments

Put simply, it is an environment which provides developers with a workspace that features programming software and other resources and processes required to develop source code for an application.

Some key components of development environments can include:

  • A physical or virtual machine, including an underlying operating system, database system, and so on.
  • Development tools, including development environments, compilers, and libraries.
  • Data management solutions
  • Associated services, including internally hosted resources and external environments, such as those running in the cloud.

Environments must be able to support a few things like:

  • Writing code
  • Debugging
  • Testing
  • Version control

The importance of these environments

All developers can find benefits to using these environments. It helps improve productivity, stability, reliability, and more towards development. The usage of these environments speaks for themselves as to just how beneficial they truly are to software developers.

Integrated development environments (IDE):

An overview of Integrated Development Environments (IDE), highlighting key features like writing, debugging, and running code.

IDEs are a very popular form of Software development environments. Some popular IDEs, a few of which you have almost guaranteed heard of, include:

  • The JetBrains environments (CLion, GoLand, PyCharm, RubyLand)
  • Visual Studio
  • Eclipse
  • XCode
  • Android Studio
A bar chart displaying the most popular integrated development environments (IDEs) from 2004 to 2019, highlighting Android Studio and Visual Studio as top choices.

What makes these environments to attractive is that they are fairly user friendly, with a little practice of course, and paired with the fact that they can be extremely customizable therefore giving a software developer the freedom to focus on other things related to their developments.

Final thoughts

Doing my research in development environments taught me just how many different development environments there are, all useful in their own respective ways, and many open-source as well. I am used to using a few IDEs like Eclipse for Java development or Visual Studio for general development but expanding my knowledge of environments is very useful for specialized projects. If you wish to learn more I would highly suggest reading this article from devzero.

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

Blog 3 – Understand clean code

Coding is just like writing an essay, it requires a logical structure, clear message, and readability so others can understand it. That’s why we need “Clean Code” in every project of programming. Clean code refers to code that’s easy to read, understand, and maintain. The ultimate goal is not just working software, but software that remains clean and maintainable throughout its lifecycle. So, how do we write clean code?

According to the Codacy article “What Is Clean Code? A Guide to Principles and Best Practices” (https://blog.codacy.com/what-is-clean-code). They provide a good explanation about clean code and how do we make the code become more understandable for others to read, and also help us to improve more in coding skill.

Why Clean Code Matters

  • Readability & Maintenance: Clear code helps developers (including new ones) understand and navigate the codebase faster. blog.codacy.com
  • Team Collaboration: When code follows shared, clean practices, it’s easier for team members to read each other’s work and contribute. blog.codacy.com
  • Debugging: Clean structure (good names, simple functions) makes it easier to isolate and fix bugs. blog.codacy.com
  • Reliability: By adhering to best practices, you reduce the chances of introducing bugs and make the code more stable and reliable. blog.codacy.com

Key Principles & Best Practices

The article outlines several principles that help make code clean:

  1. Avoid Hard-Coded Numbers
    • Use named constants instead of “magic” numbers so their meaning is clear and changeable.
  2. Use Meaningful Names
    • Choose variable, function, and class names that reveal their intent and purpose. blog.codacy.com
    • If a name needs a comment to explain it, the name itself is probably too vague.
  3. Use Comments Wisely
    • Don’t comment the obvious. Instead, use comments to explain why something is done, not what.
  4. Write Short, Single-Purpose Functions
    • Functions should do one thing (following the Single Responsibility Principle).
    • When functions become long or handle multiple tasks, break them into smaller ones.
  5. Apply the DRY Principle (“Don’t Repeat Yourself”)
    • Avoid duplicating logic; reuse code via functions, modules, or abstractions.
  6. Follow Code-Writing Standards
    • Use consistent formatting, naming conventions, and style according to your language’s community or team guidelines. blog.codacy.com
    • Examples include PEP 8 for Python or common JavaScript/Java style guides.
  7. Encapsulate Nested Conditionals
    • Instead of deeply nested if/else logic, move conditional logic into well-named helper functions — improves readability and reusability.
  8. Refactor Continuously
    • Regularly revisit and clean up your code. Leave it in a better state than when you found it.
  9. Use Version Control
    • Track your changes using a version control system (like Git). It helps with collaboration, rolling back changes, and safer refactoring.

Automate Clean Code Practices

  • Codacy recommends using its tools (static code analysis, duplication detection, code metrics) to automate enforcement of clean-code rules as you write.
  • This helps catch code-quality issues and security vulnerabilities early, keeping the codebase maintainable and high-quality. blog.codacy.com

Mindset Over Rules

  • Clean code is more than following a checklist — it’s a mindset and a commitment to quality.
  • The article argues for writing code not just to work, but to be read and maintained by humans.

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

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.

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 Uglyhttps://gerlacdt.github.io/blog/posts/clean_code/

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

What Is Clean Code? A Guide to Principles and Best Practiceshttps://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.