For my final self-directed blog of the semester, I decided to dive deeper into linters and their function. In class, we had briefly gone over linters, specifically their use to correct non-inclusive or problematic language. This is useful when creating any form of documentation because we want it to be as neutral and non-problematic as possible. I found a blog post from Codacy regarding information about linters, their benefits and drawbacks, and some popular linters for different programming languages.

The article starts by detailing the history of linters, they were created by computer scientist Stephen C. Johnson in 1978 as a tool used to find errors within written code. The name was a reference to the lint trap in a dryer, which was designed to catch the unwanted lint in the machine during the drying process. The linter is a useful tool for static code analysis, which is the process of examining errors in code before executing the code. According to the article, linters can help find “coding errors, stylistic inconsistencies, bugs, violations of coding standards, and potential security vulnerabilities.” It does this by checking your code against a predefined set of rules.

The benefits of linting are that it will reduce the number of errors written into code, it creates a consistent standard for coding practices, and can help improve the objectivity of code. Some argue that the downsides of linting include too many false positives and can negatively affect the performance of programmers in the early stages of development. However, it is generally accepted that linting is a useful tool and is adopted by many development teams.

Prior to this course and the activity we completed in class, I was not aware of linters or what they could do. Most of my code errors over the years would get cleaned up by the debugger in my IDE or by any error messages that came up upon execution. I was not aware of this as a tool that I could use in my development. Though I do not program often, or plan on pursuing it as a career path, I enjoy learning about all aspects of the field. The next time I have to do any kind of programming project, I will be adding a linter to my IDE so I can have a more consistent program with less errors. I enjoy learning more about all aspects of the field to become a more well-rounded academic and professional.

Source Article: https://blog.codacy.com/what-is-a-linter

From the blog CS@Worcester – zach goddard by Zach Goddard and used with permission of the author. All other rights reserved by the author.

For this quarter’s blog, I decided to research more into the book Clean Code by Robert C. Martin and found a blog discussing the good, the bad, and the ugly regarding the book. I chose this article because we have spent the last few classes working through POGILs related to the book. The author writes about how Clean Code has had its positive and negative impact on software development. For new programmers, the author highlights useful practices that are good for new software developers, such as good naming techniques, not repeating your code, and having functions only do one thing. On the other side, the author describes how the age of the book and its dated techniques can be considered obsolete. Clean Code was written over twenty years ago and is heavily focused on Java programming and outdated extensions that “[limit] the applicability for modern programming practices.” Another criticism by the author is that applying the rules of the book all the time can result in harmful code, such as excessive abstraction and code that is harder to maintain over time. The author argues that programmers should learn when these rules should be broken and apply them on a case by case basis.

This article was certainly helpful to give a further opinion on Clean Code and its subject matter. After going through the Clean Code POGILs in class, I had learned many things that I was not previously taught about programming. They were helpful to correct some bad practices that I was guilty of, such as commenting in place of poorly written code. However, some topics, such as the levels of abstraction or how to use classes and methods properly were initially confusing to me. It seems like the author also expresses similar frustrations in regard to these things. The author of the article describes any of the things from the book can be described in one phrase: “it depends.” Overall though, I felt it necessary to dive deeper into Clean Code for my own benefit. Even though I do not plan on pursuing a career in software development, many of these rules and structures can be applied to other disciplines within computer science and information related fields. When the time comes for me to work on a personal project or something needed for my career, I feel better equipped to handle such a task knowing what I know now. Even if some of the advice is dated, most of it can still be applied and result in better software development.

Original blog post: https://gerlacdt.github.io/blog/posts/clean_code/

From the blog CS@Worcester – zach goddard by Zach Goddard and used with permission of the author. All other rights reserved by the author.

I decided to write this self-directed blog entry on an article I found regarding information and differences between Agile and Scrum, two topics we have recently been covering in class. I sought to learn more about these two topics, as I was not entirely confident in my understanding of them. I unfortunately was absent due to an illness on the day we covered the Agile methodology in class, so in order to get a better understanding on the topic, I went through the activity and learned more about it on my own time. This article summarizes what Agile and Scrum are, their differences, the core Agile values and principles, the basics of Scrum, and when and how they should be utilized. This was quite a thorough read and was very informative to reinforce what I had learned from the class. One thing that I did not immediately connect from class was that Scrum was based on the Agile philosophies. As best said in the article, Agile is the guiding principles to shape how you work, Scrum gives a structured playbook to follow.

Though I do not plan to go into software development as a career path, I think this is still a beneficial way to learn quality teamwork and collaboration. Regardless of concentration or field of study, computer science and information systems related disciplines require efficient teamwork and collaboration. Working professionally in the field for four years now, there has never been a project or major task that involved no one besides myself. I always had to work with different teams to accomplish the final goal that was needed. Learning this framework could be very beneficial for me moving forward so I can apply it to my future professional projects. Having better tools almost always leads to a better job done, and I always strive to improve and better myself as a technology professional.

One discovery made from this article is that there are other common implementations of Agile outside of Scrum. One of these, I recognized from my professional experience, as my current organization requires all full-time staff to participate in Lean training. I was not aware that Lean training, which according to the article, “aims to eliminate waste and maximize customer value by focusing on efficiency and continuous improvement,” was an extension of the Agile methodology. This is critical, especially in the healthcare environment that I work in. It is an everchanging field and an environment that can change drastically within a matter of seconds. Though I am not a full-time employee and have yet to participate in that training, I will participate in it once I resume full-time work permanently at the end of December 2025.

ZG

The link to the blog post: https://monday.com/blog/rnd/agile-vs-scrum/

From the blog CS@Worcester – zach goddard by Zach Goddard and used with permission of the author. All other rights reserved by the author.