Category Archives: CS343

AntiPatterns: Spaghetti Code

Many AntiPatterns seem to arise when code structure is ignored and foundational concepts like those of OOPs are forgotten. Spaghetti Code is perhaps the most common and widespread of these, since it can come about so easily in nearly any program regardless of the language or paradigm. In a general sense, it is unstructured code that is difficult to read, edit, or use.

Spaghetti Code involves a very cluttered, messy design (or lack thereof). There are many moving parts which seem disorganized and generally readability is extremely, low even for the original developer. It’s much more easily found in procedural paradigms as Object Oriented paradigms were made partially to avoid this problem in particular. If Spaghetti code is found in an Object Oriented system, the structure often reflects that of a procedural program.

I’ve written about The God Class before, which is a concept that stems from similar errors, except in a slightly different form. Spaghetti Code differs from this in that the God Class has one central core class that makes extending and modifying anything more of a challenge than is necessary. Spaghetti Code generally has several large classes which run in a single, multistage process. Sometimes this kind of messy code can be found within other AntiPatterns, such as Lava Flow. Dead ends of routes taken with old projects can result in a jumbled mess of irrelevant code that is hanging around for no reason other than it is difficult to read.

So what can we do about it? Well, like many other AntiPatterns, the best solution is to take a preventative approach. Make sure that a clearly defined structure for the program is outlined before starting to develop. Make sure that when modifying the existing code, the developer adheres to the structure in place. If you’ve found yourself in a position where you need to refactor Spaghetti Code, it could potentially be a case of diminishing returns where trying to “fix” the program is more difficult than rebuilding it from the ground up. This is a massive waste of development time and money, since if a clear goal were in place to begin with the problem could have been avoided all together.

At the end of the day, a clear vision and game plan for the software you’re writing is the most important piece of development. Without a path to follow, problems become difficult to solve and solutions become difficult to implement — especially when developing a large scale software system.

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

AntiPatterns: Lava Flow

If you’ve ever contributed to Open Source projects (or ever tried to code pretty much ever), the concept of Lava Flow probably isn’t very foreign to you. 

Throughout the course of the development of a piece of software, teams take different approaches to achieve their end goal. Sometimes management changes, sometimes the scope or specification of the project is altered, or sometimes the team simply decides on a different approach. These changes leave behind stray branches of code that may not necessarily align with the intent of the final product. These are what we refer to as “Lava Flows”.

If the current development pathway is a bright, burning, flowing stream of lava, then old, stagnant, dead code hanging around in the program is a hardened, basalt-like run-off that is lingering in the final product. 

Lava Flow adds immense complexity to the program and makes it significantly more difficult to refactor — in fact, that difficulty to refactor is largely what causes lava flow in the first place. Programmers don’t want to touch code that they don’t fully understand because they run the risk of interfering with the functionality of the working product. In a way, the flows grow exponentially because developers create loose work arounds to implement pieces of code that may not even need to be implemented at all. Over time, the flow hardens into a part of the final product, even if it contributes nothing at all to the flowing development path.

So what can we do about this AntiPattern? The first and perhaps most important thing is to make sure that developers take the time to write easy to read, well documented code that is actually relevant to the final project. It is far more important to take a preventative approach to Lava Flow, because refactoring massive chunks of code takes an exorbitant amount of time and money. When large amounts of code are removed, it’s important to understand why any bugs that pop up are happening. Looking for quick solutions without have a full grasp of the problems will just continue to accentuate the original problem.

I found out this AntiPattern through SourceMaking.com’s blog on it, which delves much deeper into the causes, problems, and solutions involved with this it. I strongly recommend checking out that post as well, as it is far more elaborate than mine and gives great real-world examples along with it.

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

AntiPatterns: The God Class

We can all remember back to writing programs in our Intro to Programming course, where (if you were learning an OOP language like Java) you placed nearly everything into the main method just for the sake of learning. Projects continued to be approached like that for awhile, until you learned about inheritance and class hierarchies and why putting everything into main is actually not the best idea. It removes the basic principles of OOPs and essentially turns the project into a procedural program.

That is essentially what the God Class, AKA the Blob, does. Any related classes that are used are generally there to store data, and there is a big central class that is core to the functionality of the program. The God Class contains both operations and data relating to an extremely large amount of other classes, and acts as a controller for all of them. They generally seem to arise when time constraints and specification demands are placed on people who already have a shaky foundation in OOP principles. Either that, or often times when writing code developers will add small bits and pieces to existing software that they’re using, and some classes (especially controller-type classes) end up getting a disproportionate amount of these small changes over time.

In terms of drawbacks, there are a lot. It makes updating infrastructure far more complex than necessary, and it makes seamlessly fixing bugs in that system extremely difficult. Blobs are hard to test since there are just so many operations that work together within them, and when you create an object in memory there may be a significant portion of its’ functionality that you’re neglecting which soaks up running times.

So what can we do to refactor a God Class when we see it? First, find methods within the God Class that deal with one another and group them together. If developers have been slowly adding functionality to a controller that has resulted in a Blob-type class, then there should be a good amount of operations within it that could be grouped together. Then, either move those groups of operations into classes which they call upon in some way or create new, smaller classes which perform in the same way. Through doing this, you can extend the functionality of existing classes and reduce the complexity of your Blob. In the long term, reducing God Class complexity will assist in future testing, refactoring and will prevent annoying bugs from popping up that intrude on your beautiful OOP system design.

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

The Importance of Names

I’ve heard a lot of great things about “Clean Code” by Robert “Uncle Bob” Martin, and when I saw that the Coding Blocks Podcast had done a small series reflecting on the material of the book, I jumped right in.

Clean Code (although I haven’t read it yet) is a book that aims to set a standard in software craftsmanship, so that code isn’t lost as a result of being difficult to reuse, refactor, or even… well, read. The podcast reflected on Chapter 2 of the book, Meaningful Names. Allen Underwood and Michael Outlaw discussed major points that the chapter touched on and their personal experiences with each.

The segment that may have had the most impact on my outlook towards this subject was one of the first ones in the podcast — that the names of variables and methods should be as descriptive as possible, so that you don’t necessarily need to write a comment that explains what it does. This seems self explanatory, but I’ve already caught myself feeling compelled to comment every variable I declare in order to explain the differences between nondescript declarations like numDays and dayNum. Even if it’s just a small personal project, getting in the habit of writing effective variable names is a practice to start sooner rather than later.

They made another great point later on during the show too — Don’t be afraid of long variable/method names! So far in my educational experience, I don’t think I’ve needed to bother with a program that was more than ~500 lines total. In this case, it’s pretty easy to scroll to find what you’re looking for in each class. However when you’re dealing with a full software program, having a variable name that is easily searchable can save an enormous amount of time.

Certain topics touched on, like the “Hungarian Method” for example, I was completely unfamiliar with. I think standards like that may have been more niche or were perhaps prevalent before my time writing code. I agreed with what they said about it in the podcast, and I think the idea of a common naming convention is a good one however having code that is clear and easily readable is a better alternative.

This series of podcasts were really good, so I’ll likely be writing about it a lot more in the near future. There was a whole lot more that they went over, and it definitely made me interested in reading this book.

Here‘s a link to the episode on their website, check it out!

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

Custom Library Making Life Too Easy?

Post Referenced: https://keaplogik.blogspot.com/2013/04/java-developers-need-to-be-using-lombok.html

This particular post is in reference to the java library Project Lombok, and can be downloaded here https://projectlombok.org/download completely free. The tool can also be supported by donations and directly through their patreon page https://www.patreon.com/lombok.

Billy Yarosh describes Lombok as “a java library meant to simplify the development of Java code writing.  He then goes on to show an example of the library in use:

public class Animal {

    private String name;

   public String getName() {       

   return this.name;    

}   

public void setName(String name) {       

this.name = name;   

}

}

With the use of the Lombak library you can turn all of that code into something much smaller:

public class Animal {    

@Getter @Setter private String name;

}

I was impressed at the simplicity that this library would bring to the java language. As I always thought that Java was a bulky code that had a lot of writing involved. Especially since learning C I think about how overly complicated Java can be. The question that I raise is: does a library like this promote laziness, or does the good outweigh the bad? Personally I think a library like this is the perfect thing to have in your coding “arsenal” because it would save you valuable time to achieve the same result. However I do think that it would be important to still learn the original Java created form first, and master that understanding before using the library. Lombak should be used as a shortcut to pass monotonous material that adds up, and not to just do something easier.

 

Other advantages that Billy lists are as follows: “

  1. No more overriding toString
    • We can now annotate our class with a @ToString and lombok will override our toString method and print out the classes fields.
  2. No more overriding equals and hashCode methods.
    • Annotate class with @EqualsAndHashCode for easy generation of equals and hashCode methods at compile time.
  3. Generates constructors based on class annotations.
    • @NoArgsConstructor used for creating a no argument constructor.
    • @RequiredArgsConstructor used for creating constructor that takes one argument per non final/ non-null fields.
    • @AllArgsConstructor used for creating constructor takes in one argument for every field.
  4. Use @Data shortcut for @ToString, @EqualsAndHashCode, @ RequiredArgsConstructor, and @Getter / @Setter (on all non final fields). ”

 

Learning of a tool like Lombak has me thinking of the other libraries that may be out there to help save programmers time, and plan to look into them more in the future. Have you had any experience with Lombak, or other libraries? What were your thoughts on them?

-ComputingFinn (CS 343)

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

My First Blog Post CS 343

Welcome Reader,

My name is Andrew Finneran and this is my first blog post. ?

-Computing Finn

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

CS-343 Introduction

Hello! My name is James and this is my introductory post for CS-343, Software Design, Construction, and Architecture.

See you all in class!

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

WebStorm Shortcuts

Before I started using WebStorm for my TypeScript project, I mainly used Microsoft Visual Studio or Eclipse. Sometimes you really take for granted being able to quickly perform certain actions using shortcuts for a specific IDE. While I could have continued to use Visual Studio for TypeScript, I figured it would be best to work with WebStorm given that my professor was using it. If I ran into a Visual Studio specific problem, he wouldn’t be able to help me, so to save any potential headache I decided against using it.

Of course, it’s not like WebStorm doesn’t have its own shortcuts. In fact, I found myself instinctively using shortcuts from Visual Studio that also ended up working in WebStorm, such as the comment shortcut (Ctrl+/). Knowing these shortcuts will likely save me time in the future, so I set out to find a list of useful WebStorm shortcuts.

10 WebStorm Shortcuts You Need to Know

In the JetBrains blog 10 WebStorm Shortcuts You Need to Know, Ekaterina Prigara shares a list of the essential shortcuts that everyone should try:

  • Search everywhere: Shift+Shift
  • Navigate to declaration: Ctrl+B or Ctrl+Click
  • Code completion with replace: Tab
  • Show intention actions: Alt+Enter
  • Extend selection: Ctrl+W
  • Run: Alt+Shift+F10
  • Expand Live template: Tab
  • Multiple cursors: Alt+Click
  • New Scratch file: Ctrl+Alt+Shift+Insert
  • Refactor: Alt+Control+Shift+T

Under each command she provided an explanation of the shortcut as well as a very useful visual of the command in action. She also provides a useful resource containing a list of all the WebStorm shortcuts for OS X, Windows, and Linux located here.

I hadn’t known about the majority of these commands. The “Code completion with replace” command is particularly useful because I recall auto-completing code while trying to replace a variable and ending up with both the new and original variables. “Multiple cursors” is one of the more interesting commands in my opinion. Being able to type the same code in multiple places at once, while pretty situational, would have been able to save me a lot of time, particularly on the HTML of some of my components. Also, Scratch files are a great idea that I had no idea even existed. Being able to create code samples or make notes directly in the IDE without affecting the rest of the project is a godsend. Not only that, but the Scratch files are saved in WebStorm if I need them later.

These commands, as well as the commands found on WebStorm’s key map reference card, are probably going to save me a lot of valuable time in the future, so it’s important to learn them as early as possible when using a new IDE.

Source: https://blog.jetbrains.com/webstorm/2015/06/10-webstorm-shortcuts-you-need-to-know/

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

WebStorm Shortcuts

Before I started using WebStorm for my TypeScript project, I mainly used Microsoft Visual Studio or Eclipse. Sometimes you really take for granted being able to quickly perform certain actions using shortcuts for a specific IDE. While I could have continued to use Visual Studio for TypeScript, I figured it would be best to work with WebStorm given that my professor was using it. If I ran into a Visual Studio specific problem, he wouldn’t be able to help me, so to save any potential headache I decided against using it.

Of course, it’s not like WebStorm doesn’t have its own shortcuts. In fact, I found myself instinctively using shortcuts from Visual Studio that also ended up working in WebStorm, such as the comment shortcut (Ctrl+/). Knowing these shortcuts will likely save me time in the future, so I set out to find a list of useful WebStorm shortcuts.

10 WebStorm Shortcuts You Need to Know

In the JetBrains blog 10 WebStorm Shortcuts You Need to Know, Ekaterina Prigara shares a list of the essential shortcuts that everyone should try:

  • Search everywhere: Shift+Shift
  • Navigate to declaration: Ctrl+B or Ctrl+Click
  • Code completion with replace: Tab
  • Show intention actions: Alt+Enter
  • Extend selection: Ctrl+W
  • Run: Alt+Shift+F10
  • Expand Live template: Tab
  • Multiple cursors: Alt+Click
  • New Scratch file: Ctrl+Alt+Shift+Insert
  • Refactor: Alt+Control+Shift+T

Under each command she provided an explanation of the shortcut as well as a very useful visual of the command in action. She also provides a useful resource containing a list of all the WebStorm shortcuts for OS X, Windows, and Linux located here.

I hadn’t known about the majority of these commands. The “Code completion with replace” command is particularly useful because I recall auto-completing code while trying to replace a variable and ending up with both the new and original variables. “Multiple cursors” is one of the more interesting commands in my opinion. Being able to type the same code in multiple places at once, while pretty situational, would have been able to save me a lot of time, particularly on the HTML of some of my components. Also, Scratch files are a great idea that I had no idea even existed. Being able to create code samples or make notes directly in the IDE without affecting the rest of the project is a godsend. Not only that, but the Scratch files are saved in WebStorm if I need them later.

These commands, as well as the commands found on WebStorm’s key map reference card, are probably going to save me a lot of valuable time in the future, so it’s important to learn them as early as possible when using a new IDE.

Source: https://blog.jetbrains.com/webstorm/2015/06/10-webstorm-shortcuts-you-need-to-know/

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