I recently had a talk with one of my friends about certain ways that software should be constructed. One of the main points of discussion was the structure of classes in Object Oriented Programming, we also spoke about storage systems such as SQL and Flat File storage systems. I wanted to talk about this because it has actually had a huge impact on how I structure most of my projects made in java/C# now. For a while now the format of my code didn’t that visually appealing in the case of class structure and naming conventions. My naming conventions for the past few personal projects were very vague and once my friend gave me feedback on the code, it made me realize that when I re-read the code it came off as confusing, even though it was my project. Every project I’ve made so far after this discussion has come out to be exceptionally clean from my view point, the naming conventions are specific to their use case, the structure for classes interacting with each other is also very efficient now. I plan on continuing to use this methodology for more projects if it can fit into the scope of the project. The reason we discussed storage systems is because for a good amount of projects I’ve done terrible storage management, it was inefficient and quite ugly overall. With some projects needing a lot of data to be handled without anything being lost I would sometimes use YML, overall it is very easy to use but it was slower than other options such as JSON. Once I was shown how to implement JSON instead of YML I noticed significant changes in performance and the along with that process the code became much more readable. In regards to flat file storage, it seems to be very useful for smaller scale projects which is mostly what I work on, but in terms of larger data sets I was shown how to easily use SQL and a little bit of Prometheus to format the project even better. Since configuring and setting up flat files in a project takes a decent amount of code, setting up the database itself was way better. Using tables to grab information instead of having to manually create getters for each entry and key in a flat file was a very good quality of life update that was implemented into most of my other projects that had larger data. All I know now is that for any future projects depending on the data sets, I will be using JSON and SQL as their performance is a significant upgrade.

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

This week, I will be talking about “cheating,” or at least what some consider to be such when solving problems. Looking at the answer to a problem while learning, especially as a beginner, can be a valuable tool when used with thought and care. While some might argue that relying on solutions stifles problem-solving skills, it is important to recognize that learning is a repetitive process. When approached with the right mindset, checking the answer can enhance your understanding of the material and increase your chances of retaining that information.

First, looking at the answer can help clarify misunderstandings. Sometimes, learners might approach a problem with a misconception, incomplete understanding, or flawed method, which often leads to frustration and confusion. I can recall several times where I was required to solve a tough problem and hitting a wall when everything that I knew didn’t work for me. However, by reviewing the correct solution, they can pinpoint where their approach went wrong, gaining insight into both the problem-solving process and the underlying concept. This prevents the reinforcement of bad methods and allows for a more efficient learning experience.

In the podcast, John says, “If you’re trying to ride a bike, you’re not going to go without the training wheels on for the very first couple of runs–it’s totally okay to peek at the solution to get past whatever wall, or to see what new technology you just weren’t even looking at because you didn’t know it was a thing.” Additionally, seeing the correct answer like this can serve as a model for solving future problems. It provides an example of how to think critically and apply things in practice.

However, for this to be truly beneficial, you need to treat looking at the answer as part of the learning process, not the end. It’s important for learners to first make an honest attempt to solve the problem on their own. After reviewing the answer, they should take the time to understand each step fully, perhaps reworking the problem from scratch without referring to the solution. This ensures that they’re not just memorizing answers but are internalizing the concepts and strategies necessary for independent problem-solving.

In conclusion, looking at the answer to a problem is okay, and even beneficial, as long as the goal is learning. When used properly, it helps clarify misunderstandings, serves as a guide for future problems, and promotes deeper understanding. The key is to approach it with curiosity and a willingness to engage deeply with the material, ensuring that it enhances, rather than replaces the learning process.

This episode can be watched in full, for free here on YouTube: https://www.youtube.com/watch?v=T7AaBcNj-mA&ab_channel=noobs%2F%2FaNetworkChuckPodcast

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

Link to blog: https://codingsans.com/blog/clean-code

Clean code has been a major topic in our discussions for the past few weeks, as we’ve seen plenty of examples of both clean and bad code. We’ve learned the reasonings for why someone would write bad code, as well as the importantance of clean code. While those discussions enhanced my understanding of clean code, I wanted to take a deeper dive into it and get another person’s viewpoint on the topic. Through my research, I found Clean Code: The Manager’s Guide to Building Quality Software by Gábor Zöld.

Throughout his blog, Zöld provides a deep dive into what clean code is and why it is important, as well as general principles one should follow when writing code. He also provides advice for managers who may be looking for ways to encourage their team members to prioritize the use of clean code in their projects. He also provides an overview on the current state of software development as well as the ethics that a developer should be following when writing code.

I chose this resource because it applies to what we have been learning for the past few weeks, and it provides insight on how clean code operates in a workplace. The blog is based off of the clean code principles from Robert C. Martin, which we went over in class. This blog is also very well organized and easy to read, which shows that Zöld clearly knows what he’s talking about.

The key takeaways that I would have from reading this blog post would be to esnure that the functions that I write are as small as possible and contain descriptive variable names. I also came away with the fact that clean code actually makes you work faster, as if you are trying to push code out to meet a deadline you won’t be as efficient coding in an unorganized workspace. From an employee’s point of view, it is very important to focus on the quality of your code, as well as to understand the human aspect of it and to be trustful and understanding of other developers.

This material made me more aware of some of the bad habits that I have when writing code. I now notice that sometimes I will rush code just to try to finish it fast, but it ends up leaving a messy chunk of code that I have to reorganize later. However, if I followed the principles of clean code from the beginning, it would’ve saved a lot of time and also would’ve been more beneficial to my learning. Moving forward, I’m going to apply these principles to all of my future coding projects by focusing on the names and sizes of functions, ensuring that the names are descriptive and that they don’t take up too much space. I’m also going to apply some of Zöld’s comments regarding the workplace in the future, specifically his points of being understanding towards your other developers and coworkers.

From the blog CS@Worcester – Coding Canvas by Sean Wang and used with permission of the author. All other rights reserved by the author.

This week’s blog post is about the differences between Visual Studio and Visual Studio Code. I wrote about this topic because we just started exploring development environments, and prior to Thursday’s class, I didn’t know these were even two different software packages. I had previously installed Visual Studio on my personal computer, and when asked to install Visual Studio Code, I thought I had it already. Upon realizing they are different suites, I realized that that distinction may have been the source of a lot of confusion and issues I was running into during a previous project, and therefore is an important enough distinction to discuss in the blog post. The resource I will be referencing is an entire thread I read through on StackOverflow, which was wildly helpful in understanding some of the key differences between the two. For anybody that (somehow) isn’t familiar with StackOverflow, it is a public forum where all kinds of tech people discuss code, useful field concepts, or really anything. This specific thread was a discussion about the two software applications and the differences between them, which I chose because StackOverflow has never failed me in a time of technical need. Here are some of the key distinctions I found.

Firstly, Visual Studio is a comprehensive Integrated Development Environment (IDE) designed  for larger applications, specifically those built with .NET languages like C# and VB.NET. It offers a ton of built-in tools for debugging, checking performance, and designing user interfaces. In contrast, Visual Studio Code is a lightweight, open-source code editor that supports a bunch of programming languages through extensions. It trades off some of the advanced features found in Visual Studio in exchange for flexibility and simplicity. VS Code is well-suited for web development, Python scripting, or small coding projects. It runs efficiently on less powerful machines, which makes it accessible for developers who may not need everything provided by Visual Studio.

One of the largest distinctions is in their intended use cases. Visual Studio is much better suited for working on complex applications that require extensive debugging and testing. For example, if you’re building a massive application with multiple dependencies and a need for thorough testing, Visual Studio’s comprehensive toolset can be extremely useful. Visual Studio Code is much better suited towards working with a variety of programming languages or with a more minimalistic setup. Visual Studio Code allows you to tailor your environment exactly to your needs through extensions and customizable settings.

Additionally, they differ largely in resource requirements. Visual Studio is bulky and requires a significant amount of storage and resources. Visual Studio Code is smaller and quick to install, making it a practical choice if you don’t need a full IDE.

In conclusion, choosing Visual Studio or Visual Studio Code largely depends on your project requirements and personal preferences. Each has its strengths and drawbacks. Moving forward personally, I will be using Visual Studio Code until a need for Visual Studio arises.

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

In this presentation we are presented with a veteran of the IT industry, an author of the AGILE manifesto and manifesto for Software Craftmanship, and a man who hates that AGILE has been kidnapped by consultants and conference organizers and abandoned programmers, Robert C. Martin or better known as Uncle Bob. Now I wanted to watch this because I wanted to understand who this Uncle Bob person was and what he really meant by “Clean Code”. Uncle Bob’s first lesson starts off by giving us some examples of the scope and reality of software in our current day and age. He tells us how a person generally “can’t go more than 60 seconds without interacting with a software system” and then imparts some quick knowledge about why programmers are so slow. After this he then begins to break down this concept of “Clean Code” showing us what established and respected programmers think it us and giving us some examples of horrible first drafts of code that are nearly unreadable. Then after this showing us what refactoring this code looks like and then after this explaining some essential rules to follow when making your code clean. First and foremost, I really like listening to Uncle Bob as presents a lot of this information in an easily digestible manner and has excellent oratory skills that helped me really stay focused on the topic. The actual topic at hand was actually rather interesting, such as Uncle Bob explaining how teams get progressively slower and slower as they add features into a program due to the program becoming a bit of a monolithic mess. Or outlining a rule for functions to be as small as possible as “Long code is bad code”. Some of the topics Uncle Bob talked about were things I had no idea about like this Lambda feature he kept talking about in Java code, but that’ll have to be something I look into in the future. I think personally all of this has really given me a better perspective into what I should expect to be doing as a developer and how I should think about my code as I’m writing it. Mainly how my code should be organized and structured and especially what my workflow would look like, where I first write the code and get it working and then go back and make it clean. In the future I fully expect to be administering these principles into my code and career, and it would probably make sense to continually do this as it will not only make all my work easier for myself but also easier for my colleagues.

-Antonio Romeo

Also, here’s a link to Uncle Bob’s first lesson.

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

For my first real blog entry, I would like to talk about Code Review. I chose this topic because we are doing in-person activities based on clean code, in my Software Process Management class. When discussing how to make code cleaner and more readable, I looked more into the topic for more information. Code Review is a process performed by a person or more to examine and improve the code. I found this blog titled “How to Review Code – Tips and Best Practices” by ‘AK DevCraft’ and noticed that some of the points and practices are the same as we learned in class.

The blog highlights three important tips to be aware of when reviewing code, the first tip being Intention. This tip explained what the dos and don’ts are when reviewing code. When you review someone’s work, it’s pivotal to be positive and respectable. Giving constructive criticism, and explaining precisely what changes need to be made to improve the code. The blog also made sure to emphasize not to leave comments where you didn’t need one. Adding multiple comments to code is unnecessary and makes the code harder to read. The summary of the first tip was to be respectful to the ones who wrote the code and make it a collaboration when reviewing the code.

The second tip the author said was important was Standards. When reviewing code, making the code easy to read while making it easy to understand is what coding is all about. This can be done by sticking to a consistent format, which can be having meaningful whitespace, removing unnecessary gaps, or breaking larger functions into smaller ones. Understanding the standards of variables by creating clear and concise names for every variable. By knowing to avoid abbreviations and add values to variables such as “gallon” or “mL” to make the variable clear on what unit it is. A good practice we learned in class is to avoid duplication, duplication of code can lead to unnecessary code or more confusing messes like bugs or error messages.

The last tip the author highlighted was to review. When finishing the code review, keeping the big picture in mind can verify if your changes were necessary. GitHub is a platform we are using in class for our in-class discussions the platform has a review system to look over the source code and can help you double-check the code.

The blog shined a light on tips I believe are important when reviewing code, when my group did discussions on reviewing code, we used the same tips listed in this blog in our discussion. The blog gave me information on taking reviewing code to the next level, informing me of the GitHub feature to review the source code and always keeping a strict format in mind when reviewing code. I would recommend this blog to someone who is new to reviewing code or just wants a different approach when reviewing code with another person.

Source: https://dev.to/akdevcraft/how-to-review-code-2gam

From the blog Mike's Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.

This week, I am going to provide some insights/opinions regarding the practicality of some clean code principles, along with an example of when over-optimization for the sake of readability might actually be counterproductive. The resource I will be referencing this week can be found here. This article documents many of the same clean-code principles we discussed in class, plus or minus a few. For each principle, it provides an explanation as well as a coded example to demonstrate the principle and/or the difference between good and bad code according to the principle. I chose this article because I felt it was comprehensive enough to cover the key points for clean coding, and because I tend to use many of the principles outlined in the article in my own code.

I am currently involved in a project where the Single Responsibility Principle (SRP) might actually be counterproductive to my primary objective. In general, I tend to agree with this principle, and I understand its benefits well. It makes code far easier to read and follow, and, as we discussed in class, modern compilers can optimize functions to where there is almost no difference in execution time by offloading logic into its own function.

My program runs an ultra-fast search on a set of numbers (speaking very loosely), and needs to update numbers around 250 times per second. Thus, my time to find what I am searching for and act on it is ~4ms before all the data is useless (think: cracking Enigma in The Imitation Game). Now, factor in that I need the majority of the ~4ms to actually execute based on my search result, and one arrives at the conclusion that the search needs to take <1ms (or as little time as possible). Now to my point: sometimes, to accomplish this, I found that I had to violate the SRP. This means that I call search(), and search() immediately calls execute() if it finds what it’s looking for, eliminating the time it would have taken to return the value to main() and then pass the value back to execute(). This is obviously a miniscule difference, but in my testing and gathering data, I found that when multiplied out to larger and larger numbers, this little hack shaved off a noticeable amount of time.
This might all be more related to Command-Query Separation or the “No Side Effects Principle” than it is to the SRP, but my points still stand. What I am getting at in the big picture is that these principles, while applicable and preferable a massive portion of the time, are not always the right way to go. Sometimes, you have to sacrifice one or more in pursuit of your primary objective. All this said, my largest takeaway going forward is that I should remember and implement clean code principles whenever/wherever possible, but I will always try to remember that they are not law, and sometimes variance is necessary.

From the blog CS@Worcester – Mr. Lancer 987&#039;s Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

This week, I am going to discuss the importance of licensing your code – something that I did not know was important until this week. The blog post I will be referencing can be found here. I chose it because it provides both a simple explanation of the importance of licensing and it explicitly describes the fallacy that causes most developers (myself included) to not license their code. The blog also references some of the same specific licenses we discussed in class, which (along with some research) indicated to me that there is a small set of very popular licenses that can serve a variety of purposes and target a variety of different intents and audiences.

After reading this blog post, reading others, looking at different open source projects on GitHub, and having discussions in class, the conclusion I’ve come to is this: the top reason people don’t license their code is because they don’t understand that licensing actually gives people more rights, not less. Many (again, my prior self included) likely think that if you just code something and throw it onto GitHub, that anybody can use it as open-source. This is not the case; that is actually incredibly restrictive, because you own the copyright to that work, and nobody can use that code without running into some legal barriers. Whether those barriers will ever be realized is another question, but not including a license may be enough to deter people from expanding on your work. A well-chosen license clearly communicates how others can use, modify, and distribute your work. This not only protects the rights of the original creator, but also allows others to expand on the work without the constant worry of stepping on legal toes. Licensing is better thought of as a way to invite others to engage with your code, rather than a barrier that restricts access.

The MIT License, to give an example, is concise and straightforward, allowing users to do almost anything with the code, as long as they include the original license and copyright notice. This simplicity has made it a favorite in the open-source community, encouraging collaboration and making it easier for developers to share their projects without too many legal constraints.

Understanding code licensing not only protects your work but also leads to a more collaborative and innovative development environment. Whether you want to encourage broad usage with an MIT license or ensure that your project remains open-source with a GPL, the right license can significantly impact how your code is shared and utilized. Moving forward, I plan to include licenses in any open source code I write. Though I never thought it was important before, I’ve learned now that it actually is critical if I want my code to actually be usable by others.

From the blog CS@Worcester – Mr. Lancer 987&#039;s Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.