This week, I read the informative post “How to Write Clean Code” from the freeCodeCamp blog. A thorough review of best practices for creating clear, manageable, and effective code was provided in the article. As I work to improve my software development abilities, this website has been really helpful in helping me better grasp clean code concepts. I selected this article because it immediately aligns with the course objectives, which prioritize process-oriented thinking and strong programming methods. Professional software development requires clean code, and becoming proficient in it supports the larger goal of becoming a skilled developer who can contribute successfully to group projects !! The article introduces the concept of clean code, which is described as code that is simple, transparent, and free of excessive detail. It covers specific activities, such as assigning descriptive and informative names to variables, functions, and classes. Creating functions that serve a specific, distinct purpose. Combining repeated logic for easy maintenance. Writing self-explanatory code and reserving comments for complex logic or critical context will help you avoid using unneeded ones. Use rigorous unit tests to ensure that the code works as intended. As a brief aside, the author emphasizes the need of developing these techniques into routines and incorporating them into daily coding operations. I realized after reading this post how frequently I ignore little but important details of code quality. For example, I have been guilty of using vague variable names like temp or data when my code would be easier to comprehend with more descriptive names. I found that developing large, multi-task functions makes debugging a headache, thus the remark about writing tiny, single-purpose functions caught my attention. I was able to relate clean code techniques to more general course ideas thanks to this resource. The concept of removing duplication, for instance, is closely related to software design concepts like DRY (Don’t Repeat Yourself), which we have covered in class. Similar to this, the emphasis on meaningful names is in line with our goal of communicating clearly, both when writing code and when recording procedures. In the future, I plan to apply what I’ve learned by revising my code to ensure that functions are clear and effective. Using descriptive terminology to improve text readability. Unit testing should be prioritized in order to identify and resolve issues early in the development cycle. These changes should make it easier for me to stick to my own responsibilities and contribute more consistently to group projects. My experience with clean coding will also be useful in real-world scenarios where teamwork requires efficiency and clarity. This article served as a helpful reminder of how crucial clean coding techniques are to meeting industry standards for software development. As I progress through this course, I’ll make an effort to incorporate these ideas into my workflow so that the code I write is not just useful but also readable and manageable.

Cocca, G. (2024, September 11). How to write Clean Code – Tips and Best Practices (Full Handbook). freeCodeCamp.org. https://www.freecodecamp.org/news/how-to-write-clean-code/

From the blog CS@Worcester – Just A Girl in STEM by Joy Kimani and used with permission of the author. All other rights reserved by the author.

Hello, this is my second topic-based blog and today I will be talking about something I learnt about in depth over several days in my Software Process Management class. This was a very interesting topic and I learned a lot of things about code that I had previously not known about. Some of the things that I was taught in my earlier days of coding were proven to not be the best way to go about making organized, clear code. One example of this is that I was originally taught to make comments after most lines of code, just to make sure everyone reading the code will understand it. However, it turns out this was just a beginner step to help myself learn. In reality, clean code should be easy to read and understand, making many comments obsolete.

Now I will talk about some examples of obsolete comments. One of these are redundant comments. These are comments that are unnecessary. An example of this would be: z = x + y (sets z to the sum of x and y). As you can see, the code speaks for itself, and this comment is completely obsolete. Another comment type that is unnecessary would be misleading comments. These comments are usually created when someone forgets about a comment after updating the code. This leads to the wrong comment being on a block of code that doesn’t even do what that comment states!

The blog I researched for this post is linked here: Writing Clean Code: Tips and Best Practices – DEV Community

Unsurprisingly, this blog shared many of the same values that I learnt about in class. It gave me an overview of the material I had gotten an in-depth understanding of, with many additional helpful tips and tricks. This blog mentioned using meaningful names for your classes, functions, methods, and variables. This ensures that someone else who is reading your code can easily understand EXACTLY what everything is used for. Ex) “bananas VS. bananasInBasket”

Another thing that this blog shared with what I learnt about is to make sure functions and methods are small and limited to a specific number of lines. You don’t want an entire code that may be repeated inside one method. Instead, create a function that you can call inside the method to keep the code clean.

The website also mentioned good practices for making comments, and to make sure you refactor your code a lot over time!

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

Hello Debug Ducker here, and today this piece will be a bit different. I want to share my opinions and others about on a somewhat controversial figure in the coding community. Robert Cecil Martin also known as Uncle Bob is a well-known software engineer. He is known for many things such as the subject to today’s topic, “Clean Code” a book written by him that discusses and shares what clean code is. it offers advice on how to structure and write code for it to be “clean”.

From my experience from reading excerpts from the book and trying some of his advice on an old project of mine, I have found that it has made the code a lot more readable. However there is some advice that I don’t agree with. To paraphrase, Uncle Bob mentions that a function should avoid having more than one argument or have none at all. He saw that the more arguments, the less clear it is. I understand what he means but personality I feel this may not apply to all cases when writing code, especially if you need multiple arguments to achieve something, so the advice is situational. It made me curious to do a bit of research myself on what others may think of his advice, and I found an article that shares similar sentiments about the advice given by Uncle Bob.

The blog is from a username qntm, who is a novelist but also a programmer. The blog entry is called “It’s probably time to stop recommending Clean Code”, and as the name may suggest, is an opinionated piece on the book of the same name by Uncle Bob. The blog entry had critiques about the book, such as the advice from Uncle Bob that said functions should only be about 3–4 lines. The user qntm found this bizarre, and frankly, I did too as I find this very restrictive for making functions.

That is just one of the many examples from the blog entry, and I would advise you to check the blog yourself to read the full thing. I’ll provide a link below and perhaps search for his other entries as well. I wanted to show you this because the definition of clean code perhaps can’t be defined by one person. Though I have found some of Uncle Bob advice to be helpful, I don’t think all of it should be taken as gospel. Apply his teachings where it may help and perhaps consider finding other ideas of clean code elsewhere because Robert is just one man who wanted to share some advice, I am sure others have different ideas that may help you as well.

Here is the blog entry by qntm about the subject for those curious

It’s probably time to stop recommending Clean Code. Things Of Interest @ Things Of Interest. (2020, November 28). https://qntm.org/clean

Martin, R. C. (2016). Clean code Robert C. Martin. Addison-Wesley Professional.

From the blog Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Intro

Have you ever forked a respository without looking at its software license? It’s easy for developers to unintentionally violate licenses, especially if they aren’t informed about what they are, leading to potential legal troubles. This blog post by Fernando Galano breaks down the complexities of software licensing, providing clarity on a topic that is often overlooked, but is vital for anyone involved in software development.

Summary of Source

The blog post explores the concept of software licensing, covering its purpose, types, and implications.

1. What is a Software License?: An explanation of how licenses define the terms under which software can be used, modified, and distributed.
2. Types of Licenses: An overview of open-source and proprietary licenses, including popular ones like the GNU General Public License (GPL), MIT License, and Apache License. It also explains what a copyleft license is as well as what a permissive license is.
3. Why Licensing Matters: A discussion of how licensing affects collaboration, compliance, and intellectual property rights. It describes the benefits of licensing from the standpoint of both developers and users.
4. Best Practices for Choosing and Using Licenses: Practical tips for selecting appropriate licenses for projects and understanding license compatibility.

The blog is an introductory resource for open-source software usage and distribution. It doesn’t go into excruciating detail, with pages upon pages of technical terms, but it does cover the basics and anyone interested in furthering their knowledge on software licenses should explore more sources.

Why I Chose This Blog

I chose this blog because it addresses a topic that is often overlooked in technical coursework but is integral to professional software development. As I aspire to work as a software developer, understanding licensing will help me avoid legal complications and help my work be protected. The blog’s concise explanations and practical examples make it an ideal resource for building foundational knowledge in this area.

Reflection of Source

The blog post provided a clear and structured overview of software licensing, breaking down confusing legal jargon into digestible information. One aspect that particularly stood out to me was the explanation of the differences between permissive and copyleft licenses. For instance, I now understand how the MIT License offers flexibility by allowing modification and redistribution with minimal restrictions, while the GPL ensures that derivative works remain open-source. Reading about software licenses makes me realize how easy it is to unintentionally violate licensing terms due to a lack of awareness. Before learning about licenses I had never even considered that I might be violating the original creators intentions when deriving their work. This blog has made me more vigilant about understanding and respecting licensing terms, ensuring that my future projects remain legally sound.

Future Application

As I move forward in my career, the knowledge gained about licenses will shape how I approach software usage and distribution. When contributing to open-source projects, I will carefully evaluate license terms to make sure it aligns with my goals. Also, while working professionally, I’ll advocate for the proper review of licensing agreements to prevent legal risks. This understanding also allows me to choose the right license when publishing my own work, depending on the terms I would like others to follow. By adhering to licensing norms, I aim to contribute to a more ethical and collaborative development environment.

Citation

Understanding Software Licensing by Fernando Galano https://www.bairesdev.com/blog/understanding-software-licensing/.

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

In today’s world of software development, understanding copyright and licensing is crucial for ensuring compliance with intellectual property and collaborative innovation. Developers often work with software libraries, tools, and frameworks created by others. Without a solid grasp of licensing terms, there’s a risk of infringing on someone else’s rights or unintentionally exposing some proprietary code to the public.

What is Copyright in Software?

Software copyright provides legal protection for the code written by developers, categorizing it as intellectual property. It grants the original creator exclusive rights to use, modify, distribute, and license their work. In most jurisdictions, as soon as a piece of code is written, it’s automatically copyrighted, even without a explicit registration.

However, copyright doesn’t cover ideas, or methods used in the software it only protects the specific implementation of those ideas in code. This means that while you can’t copy someone’s code without permission, you can write your own implementation of a concept.

The Types of Software Licenses

In class we learned about Software licenses and how they specify the terms under which code can be used, modified, and distributed. They range from very permissive to highly restrictive. Some common types include:

1. Open Source Licenses: These allow anyone to view, use, and often modify the code. Examples include:
   • MIT License: Permissive, allowing almost any use, including commercial purposes, as long as the original copyright notice is included.
   • GNU General Public License (GPL): Requires that any modified version of the code also be released under the GPL, ensuring that derivative works remain open.
   • Apache License(s): Permits use and distribution, even for commercial purposes, but includes a clause protecting contributors from patent claims.
2. Proprietary Licenses: These are restrictive and usually prevent users from modifying or distributing the software. Examples include end-user license agreements that accompany commercial software for example like Microsoft Office.
3. Creative Commons Licenses: While more common in creative works like music or literature, some software projects use Creative Commons to specify usage rights.

How to Choose the Right License

When releasing software, selecting the appropriate license is vital. If you want maximum collaboration and sharing, permissive licenses like MIT or Apache might be ideal. However, if you want to ensure that your work remains open source in derivatives, a copyleft license like GPL is a better choice.

Key Takeaways:

1. Read the License: Always read and understand the terms before using third-party software. Misinterpreting a license can lead legal issues.
2. Attribute Properly: Many licenses, even permissive ones, require attribution to the original author.
3. Derivative Rules: If you modify software under a restrictive license like GPL, you must release your changes under the same license.
4. Protecting Your Work: If you’re releasing your own software, choose a license that aligns with your goals for sharing or monetization.

Resources

• GNU Operating System: Licenses
• Choose an Open Source License
• Refactoring Guru on Software Licensing
• https://www.10duke.com/resources/glossary/software-copyright/

From the blog CS@Worcester – function & form by Nathan Bui and used with permission of the author. All other rights reserved by the author.

While writing software it is important to know, how to maintain clean and understandable code. Despite best efforts, developers can unintentionally introduce code design smells precise indicators of deeper design problems. While these smells don’t directly cause bugs, they reduce code readability, maintainability, and scalability.

In class we learned the 6 common Design Smells, so I referenced the class materials and found an helpful article on Refactoring Guru. This webpage offers a practical explanation of common smells such as long methods, large classes, feature envy, and shotgun surgery.

Why I Selected This Resource

The reason why I chose this resource resonates with the principles we’ve covered in our class on software design and architecture. Its structured, accessible approach demystifies complex design issues, offering developers clear steps to refactor and improve their code. I’ve often seen myself facing challenges and struggling with tangled code where debugging or adding features feels almost somewhat overwhelming. These tools and insights help a and provide a roadmap for addressing such challenges systematically, and thoughtfully throughout the design process.

My Reflections on the Resource

The discussion on bloaters, like long methods and large classes, I think this was particularly something worth learning. These smells arise when a method or class tries to handle too much, violating the Single Responsibility Principle. I realized that in past projects, I’ve struggled with methods growing unmanageably large as features were added. Refactoring Guru suggests breaking these methods into smaller, more focused ones using techniques like extract method, improving both readability and reusability.

Another key takeaway was the concept of change preventers, such as shotgun surgery, where making a small change requires altering code in multiple places. This often signals that responsibilities are poorly distributed across the system. The resource recommends consolidating functionality into a single class or method, reducing the risk of errors and making future updates more straightforward.

Applications for Future Practices

Refactoring Guru’s emphasis on identifying smells early and refactoring incrementally aligns well with agile development practices. Moving forward, I plan to use this more than one of these materials as a checklist during code reviews to spot and address issues proactively. Techniques like extract method, extract class, and move method will hopefully become part of my tools for tackling coupled code. By continuing improving my skills to detect and refactor code smells, I want to create cleaner, more sustainable codebases that will be easier for both my team and future developers to work with. Thank you for reading my blog post and I hope you learned some

https://refactoring.guru/refactoring

https://refactoring.guru/refactoring/smells

From the blog CS@Worcester – function & form by Nathan Bui and used with permission of the author. All other rights reserved by the author.

Intro

Imagine inheriting a massive, poorly designed codebase. Every change you make breaks something else. For software developers, such nightmares can be avoided by adhering to the SOLID principles, a foundational guideline for creating maintainable, scalable systems. These principles are a must-know for any software developer seeking to improve the quality of their work. They provide a roadmap for developers to create cleaner, more maintainable codebases, which is why I was drawn to this resource

Blog Summary

The blog goes through each of the five principles, explaining what they are, why they are important, and giving a code examples utilizing each one.

1. Single Responsibility Principle (SRP): A class should have only one reason to change, ensuring focused and cohesive functionality. The blog illustrates SRP with an example of separating user management from content creation, showing how this approach simplifies debugging and enhances code clarity.

2. Open-Closed Principle (OCP): Software entities should be open for extension but closed for modification, promoting adaptability without risking existing functionality. For OCP, the blog demonstrates how using inheritance and interfaces allows developers to add new functionality, using Square and Rectangle classes inheriting from the Shape base class.

3. Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types without altering the correctness of the program. The example provided for LSP highlights how properly designed subclasses, such as an Eagle and a Penguin inheriting from a Bird class, ensure seamless substitution without breaking the program.

4. Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use, encouraging lean and specific interfaces. In discussing ISP, the blog uses an example of splitting a large interface into smaller, more specific ones, ensuring that classes only implement what they actually need.

5. Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules but instead rely on abstractions. For DIP, the blog explains how decoupling high-level modules from low-level details using abstraction layers, like interfaces, makes the codebase more flexible and easier to maintain.

Why I chose this resource

I selected this blog to write about because it breaks down each principle in a concise way, clearly explaining each one in a way that is easy to understand at all levels. It’s a great resource to quickly go back to when you need a refresher on any of the principles.

Reflection on SOLID

After learning about SOLID, I see that it might take an extra step of thinking to adhere to the principles at first, but I think it’s well worth it for the resulting code structure. The easy way to code is messily throwing together code that works without a second thought, but doing that is very dangerous for the longevity of a program. I believe that after following SOLID for a while it will become second nature and will become the natural way of coding, which is why I think it’s important to learn about SOLID early and consciously until it does become a subconscious practice. In one of my past projects, I struggled with messy code that implemented multiple responsibilities in one class. Debugging it was a nightmare, but had I known about the SRP principle it could have been avoided entirely. Reflecting on these principles has already influenced how I plan on approaching my code, and I’m eager to incorporate them into my future work.

Future Application

Given the importance of SOLID principles for large-scale software, I believe it’s essential to internalize and apply them in future projects to thrive in the software development space. By crafting modular classes and reducing dependency, I aim to create services and systems that are easy to maintain and adapt as requirements expand and evolve.

Citation

“Essential Software Design Principles You Should Know Before the Interview” By Arslan Ahmad

https://www.designgurus.io/blog/essential-software-design-principles-you-should-know-before-the-interview

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.