What is Smelly Code and Why Your Code May be Stinking Up the Room

Code Smells. Kind of a strange phrase, isn’t it? At least I thought so while perusing Professor Wurst’s concept diagram. I decided to look it up out of curiosity and found some interesting information on it.

Well, what exactly does it mean? In short, code smells is basically code, trends, patterns, etc. that indicate there may a be an underlying issue with the code that could cause issues later down the line and/or is already causing problems. Now, that doesn’t mean the “smelly” code will always cause problems. It could be there for a specific reason. Perhaps it has to handle an odd scenario or something similar, but the point of knowing what smelly code is to be able to determine where there my be common issues or bad habits. In his blog at codinghorror.com, Jeff Atwood dives into some signs of stinky code…

Going through his list, there are several that stuck out to me. The first couple involve length. Long methods are trouble for several reasons, but perhaps the most important is they can be hard to read and trouble shoot. Atwood mentions that methods that are significantly longer that the rest of the methods in the class/program are often trouble and it is a good idea to break it into smaller methods if possible. He also mentions lengthy parameter lists. The more parameters, the longer and more complex the method is going to be. I have to say I agree with both of these. Nothing is worse than trying to read through an endless block of code. Items can get lost and users can easily get confused or lost while trying to decrypt what is going on.

Next on the list are “oddball solutions”. If there is a problem that needs to be solved multiple times, there should only be one way of getting to that solution within the code. There may be multiple ways to get to an answer (i.e. 5*1 = 5 and 1*5 = 5), but the way of getting to the answer should be consistent throughout your code. I agree with his thoughts here. Seeing two different equations to get to one solution could certainly confuse the reader. Not to mention that if the process is the same it should probably just be put into a method anyhow.

Last on the list this week are temporary fields. Make sure that all the fields are actually needed. Unnecessary fields can cause, you guessed it, confusion. The user may think they are needed for some reason and may deem the program to not work properly or something similar. Not to mention that fields that need to be filled out each time the program is run can be extremely annoying while trying to test, so you are doing yourself a favor by keeping the number of fields down as well.

Since I have found this blog particularly useful and insightful, I plan to continue with a part two next week, so stay tuned.

Link:

https://blog.codinghorror.com/code-smells/

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Ethical Hacking

Source: https://www.computersciencezone.org/what-is-ethical-hacking/

This week I found a blog called computer science zone. There was this one blog that caught my eye which was called What is Ethical Hacking? Ethical hackers sound like an oxymoron because when you think of hacking you think of people who break into people’s computers, small business accounts, and websites. Where they would go on and steal personal information such as bank accounts, addresses, social, and many other things. The people that I was just talking about fall into the category of black hat hackers. However, there are hackers that are not all about stealing information their people are called white hat hackers. These people are actually hired to hack into company’s websites to find security leaks or holes so that way they can take care of it before someone who is trying to do serious damage can find it. There are a few specialists that this blog talks about as well such as information security analyst, security engineer, and penetration tester. As an information security analyst, they are responsible for solving security problems are companies and origination with substantial technology and informational infrastructure. Because of this there are a team of it professionals that monitor the database for these companies and they even ward off cyber-attacks daily. With security engineer, they are responsible for beefing up the security that they have and even creating new and effective ways to make the security for the company even stronger. With penetration tester, they are responsible for maintaining secure connect ability between internal and external communications. This means that they are often between email servers and accounting and communication software and the internet to keep hackers from invading those firewalls.

I like this blog a lot because it talks about a few future jobs that we have available to us as computer science majors. They even give the amount of money you make what you do at the work place and where they are usually at. This blog is very cool to read because when I was taking data security we learned about white and black hat hackers and I was very into that topic that it was really cool to see that there are different types of hackers in the work and not all of them are out in the world trying to do evil. So, it is nice to see that with computer science we are able to do many different jobs with many different people from small business and even muli-billion dollar companies.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Ethical Hacking

Source: https://www.computersciencezone.org/what-is-ethical-hacking/

This week I found a blog called computer science zone. There was this one blog that caught my eye which was called What is Ethical Hacking? Ethical hackers sound like an oxymoron because when you think of hacking you think of people who break into people’s computers, small business accounts, and websites. Where they would go on and steal personal information such as bank accounts, addresses, social, and many other things. The people that I was just talking about fall into the category of black hat hackers. However, there are hackers that are not all about stealing information their people are called white hat hackers. These people are actually hired to hack into company’s websites to find security leaks or holes so that way they can take care of it before someone who is trying to do serious damage can find it. There are a few specialists that this blog talks about as well such as information security analyst, security engineer, and penetration tester. As an information security analyst, they are responsible for solving security problems are companies and origination with substantial technology and informational infrastructure. Because of this there are a team of it professionals that monitor the database for these companies and they even ward off cyber-attacks daily. With security engineer, they are responsible for beefing up the security that they have and even creating new and effective ways to make the security for the company even stronger. With penetration tester, they are responsible for maintaining secure connect ability between internal and external communications. This means that they are often between email servers and accounting and communication software and the internet to keep hackers from invading those firewalls.

I like this blog a lot because it talks about a few future jobs that we have available to us as computer science majors. They even give the amount of money you make what you do at the work place and where they are usually at. This blog is very cool to read because when I was taking data security we learned about white and black hat hackers and I was very into that topic that it was really cool to see that there are different types of hackers in the work and not all of them are out in the world trying to do evil. So, it is nice to see that with computer science we are able to do many different jobs with many different people from small business and even muli-billion dollar companies.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

CS@Worcester – Fun in Function 2017-10-09 23:59:28

The blog post this is written about can be found here.

This blog post by a software engineer working at Facebook outlines several anti-patterns, including examples, why they’re bad, how to avoid them, and why it’s difficult to avoid them. I chose it to read because of the obvious connection to the course material, my continuing desire to avoid bad practices, and the fascinating connections the blogger makes to the cognitive biases that explain why we fall into these traps.

Some of the anti-patterns are time-wasters, like bikeshedding and analysis paralysis. Bikeshedding is described as the tendency to spend a disproportionate amount of time debating unimportant details. The blogger suggests flipping a coin or voting when you notice this problem arising. You can resolve to revisit the decision at a time when it’s more relevant, as long as you get the decision over with quickly and move onto more important ones.

Analysis paralysis is analyzing so much that it impedes progress. The blogger suggests that this anti-pattern crops up due to information bias and validity bias. Information bias is defined as the belief that you can make better decisions the more information you have, regardless of whether the information is relevant to the decision. Validity bias is overestimating how accurately you can predict an outcome based on a set of information, even if that information is unreliable or outdated. These can lead us to the belief that more analysis will be useful, even when it won’t. His solution to this anti-pattern is more iterations of code. If you go ahead and try something, you can see actual outcomes and modify your code accordingly, instead of endlessly speculating about outcomes.

I also took note of several class-related anti-patterns. These include the god class, a class that knows about and/or controls too many classes; fear of adding classes, the avoidance of adding classes due to a misconception that they will make designs more complicated; and the poltergeist class, a useless class that ought to be eliminated. The solutions for the first two seem to contradict the solution to the last one, but taking all three into account leads to a clear picture of how to properly use classes.

For the fear of adding classes, the blogger gives a useful example of a tangled ball of yarn to represent too few classes. Adding classes can instinctively feel like adding complexity, but simplifying your design with additional classes is akin to separating the yarn into individual strands. Similarly, the god class can be broken up according to the single-responsibility principle, giving classes only one clearly-defined responsibility. Poltergeist classes lack a clear responsibility; they often only call other classes or add a layer of abstraction that isn’t actually necessary. When you create a new class, you should make sure it actually has a valuable role and simplifies the design.

Hopefully, having read this, I will be able to recognize these anti-patterns in the future and apply their relevant solutions.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

HashMaps

 

Today I read an article on coding-geek.com about HashMaps. I have used HashMaps before in Data Structures as well as Unix systems and have found them to be a very resourceful way to store and retrieve data. Most developers know about HashMaps but don’t completely understand how they work, in todays blog we will be cover HashMaps in JAVA.

HashMaps have an inner class called an Entry Class which holds the key, values and will return a value at the end. Two important main methods in the class are put() and get(). put() associates the specified value with the specified key in the map, it checks if the key given is null or not. If the given key is null, it will be stored in the zero position. The next internal part of the put method is that it fits the values inside of the limits of the array. The get() method is very similar to the put method but instead of storing, it returns a value. Get() gets the hashcode of the main object and finds the location of it in the array. If the right value is discovered, then it returns the value but if it cannot find it then it returns null. Put() and get() are two major internal parts of HashMaps and looking back at some of my old projects with HashMaps I now fully understand what is going on internally when I execute the program. I will use HashMaps more frequently in my projects now and I hope that after reading this you will be able to understand HashMaps better and will be able to give them a shot.

Source: http://coding-geek.com/how-does-a-hashmap-work-in-java/

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

Clean Code Principles

In this blog post, Marcus Biel gives his thoughts on clean code, what that is, how to implement, estimate, and accurately design good software that does exactly what it should and nothing more. What is clean code? The author writes,

“It’s the idea that your code should be precise and as close to perfect as possible. If you have more code than you need, it shouldn’t be there.”

This concept relates to YAGNI (you ain’t gunna need it), and is an essential part of having clean and readable code. Adding features that might be needed later is a good way to bloat your code and run into bugs. Clean code requires time to fully understand the problem, this is sometimes tough when working in an environment where you are being pushed by those who don’t understand what goes into software design. Sometimes you will be asked to meet deadlines that will make you rush, in turn you can end up with poorly written code. The language and wording in code is also very important, using variables and names that are clear and make sense help others read and understand what is going on in your code. I selected this resource because having clean code is a huge part of being a good programmer, along with tips on clean code, the author has tips on designing code by running tests first, working with co-workers and clients to understand what features are most important, and what features are not beneficial.

“To me, being a software craftsman is about having a focused attitude and about taking responsibility for your code, your job, and your time. So, from beginning discussions to end results, your one focus should be on maintaining your own high standards and creating the best possible product for your client.” – Marcus Biel

This post had a good amount of information and insight on clean code, and being a good developer in general. Important aspects from the post I think are being clear when naming variables, methods, and classes, leaving out code that is not needed (YAGNI), and making accurate timelines for projects. Rushing to write code before you fully understand the problem can lead to more problems down the road. I expect to use concepts of clean code in my professional career, I believe it’s very important to make a good product that will benefit you, your company, or your client.

The post Clean Code Principles appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Test Design Techniques

We’ve discussed quite a few different testing techniques, so I would like to offer some personal reflection on what we’ve learned so far. Udemy has a great blog highlighting many of these techniques; it is entitled Test Design Techniques You Need to Know. I will summarize some points from Udemy’s blog which I feel directly relate to what we’ve discussed in class so far.

Udemy begins by explaining the concept and importance of Software Testing, which I feel is an intricate part of Software Development itself.  As we’ve learned in class, we test our software to ensure the quality and integrity of our products. We want to be able to detect and fix any flaws in our products before they reach the consumer.

Udemy classifies testing techniques as a whole into two general categories: black-box and white-box. We’ve learned in class that we do not need access to the actual code to perform black-box testing of a product. In contrast, we ought to have access to the program’s internal structure and/or source code to perform testing techniques in the white-box category.

Many of the techniques we’ve discussed in class seem to fall within the black-box testing category, so I will focus primarily on that category. Udemy lists some techniques of black-box testing, three of which sound very familiar due to what we’ve done in class:

  • Boundary value analysis: This is where we test the lower and upper limits of possible inputs. After finishing a class project and reading thoroughly about this technique, I feel that if our code is going to fail, there is a significant chance in finding these errors somewhere close to the minimum, nominal, maximum range.
  • Decision table testing: Udemy describes this as evaluating conditions of our code within a table, where every decision correlates with a relation, predicate or variable. The blog cites this technique as “providing great confidence in the test cases.” I tend to agree with this statement because as we’ve learned in class, decision tables are good at analyzing complex logical relationships within our projects.
  • Equivalence class partitioning: We use this technique to partition a complete set into subsets, and test each of these “equivalence classes.” Since we’re partitioning the sets, I believe this technique can be used as an efficient way of reducing the total number of needed tests as a whole.

Udemy concludes by explaining that a decision test design technique is the best way to obtain absolute logical coverage. I would like to learn more about this topic; perhaps we will be discussing it in class soon. The blog also emphasizes that we ought to use boundary value analysis and equivalence partitioning to cover a wide range of inputs.

After reading Udemy’s blog, I am convinced that all of the summarized techniques are used everyday in Software Development as a whole. Thus I am confident I will be using many (if not all) of these techniques in my professional career.

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

10/9/17 Software Design Writing

https://www.toptal.com/freelance/why-design-documents-matter

This week I read on why writing a software design document matters. This blog goes through the steps of what is needed in a design document. The program idea could start with a call or Skype meeting between the programmer and the client, with the client telling the programmer what he wants in the programmer. The programmer is then left to create the program once and outline is created, and meets up with the client one last time when the program is finished to make sure it is what he wants. Chris Fox, the author of the blog entry, goes through each of the steps with a brief summary and a picture or diagram of what each of the steps would look like. The specification of a software design document show that the design goal of the project is going to be. This is created by the developer and the client on what is needed to be done and how the program or in this case application should work. The interface is the framework of the application. This is also the most problematic trying to get it to look perfect to what the client wants. Functionality how the application works and what it is supposed to do. Milestone, what the application is supposed to do once finish. The blog also gives examples of outlines for the document which features all of the steps. The outline should include the goals of the program, the function of the program, the users’ interface, and its milestone.  The author’s example of a UI description that he used was for an app used on an iPhone. The description included a navigation bar that controlled the app and where to go to different locations of the app, and a table of a layout of what will appear on the screen of the phone, including images and texts. Steps may change overtime as the application is being designed and programmed. The author gives us these steps and what to do as an example of a free lancer with one client.

This was another interesting blog. This blog showed another reason why we need a design map or outline for any programming. The diagrams show how the steps for the outline works, whether it is written on paper or typed up on the computer, both show the outline for the program and how it is expected to run for the user. Not only does this design work for programming site, it also works with programming applications. This shows that you need a design outline or diagram before creating any kind of program. This blog gives another method for designing a program. I would probably create an outline of what the program needs to do and how it should run, create a UML diagram for it then try to create the program itself.

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

Potential Future Traps

After the last post my mind has been on the future of software testing, but after a week or so it’s taken a bit of a journey and now I’m wondering about my future in software testing. And as it usually does when I think of the future, negativity is on the forefront. Which is why potential pitfalls are something I’m really interested in. So wonderfully, I found a helpful post on Awesome Testing listing possible software testing traps and describing them. The ‘traps’ in this case are mistaken implementations or uses of software testing that lead to very unfortunate results, based on the authors own experiences and what he has read or discussed with others.

It is incredibly interesting seeing the ways companies mistakenly attempt to optimize use of testers. Rating them on the amount of bugs found or incentivizing them to find as many bugs as possible only were issues that seem obviously awful to me, but I have hindsight on my side. A good amount of the traps were something I didn’t consider, issues with not having developers do any testing themselves. By leaving only testers as the ones to run tests and do quality assurance, it led to developers using testers being turned into scapegoats for issues or testers becoming a commodity that is moved around too often to do their job correctly.

Trap number three shows the human side of the process, to me at least. If testers make bad tests and have to constantly fix them, or the tests offer very little information due to their issues, then developers become disillusioned with them. It becomes safer and more likely for the tests to become more and more ignored. Software testing is not just finding bugs in programming, it must do so reliably and in a way that aims for improvement. Developers and testers are also not as  clear cut as one would think. Or they shouldn’t be, at least.

I feel much more confident now knowing many of the issues that one can accidentally fall into in the process of software creation and testing, and how to possibly avoid them. I also found the idea of testing not simply being about finding bugs, but just a part of a greater system working towards an end goal of a wonderful software product insightful. It is incredibly useful to understand the full Software Engineering Life-Cycle no matter where your job lands on it.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

Seven Hints of Design Smells

This week I have decided to read about “Design Smells” from Bartek’s Coding Blog. So, while   this blog is rather short, the reason why I have chosen this one in particular is because recently in my studies, my biggest question that how do people figure out the errors of a design without testing or even refactoring. I want to understand the logical thinking in recognizing the errors that point to a wrong design.

This blog post basically goes over seven hints of design smells that points to places that the code is not going as intended. These seven hints are rigidity, fragility, immobility, viscosity, needlessly complexity, needlessly complexity, and opacity.  For rigidity and fragility, they point to the belief of a simple change will fix everything but other unexpected things can happen and the code can fall into pieces. Immobility and viscosity, on the other hand, point to “moving” and using codes to be improving the design but preserving it while implementing new features might be difficult. Needlessly complexity and repetition are easy to understand. They point to implementing something complex and copy and paste that is not needed at all. As for the last hint, Opacity, points to making a code clear and easy to understand.

So, based on the blog post with the insights I find behind it, I would say this was a simple but interesting blog to read. The author explained each of the seven hints with a simple take of every day programming work while giving the literal term along with it. From my experience in finding something wrong in a design, it’s usually testing which takes a considerable amount of time depending on how much writing there is into it. If there are unrelated errors occurring within testing, then it would be where I will try to figure out which part of it is the source of the problem and then try to debug it as much as possible.

From this blog about design smells, what I learned is that to avoid conflicted attention described by the hints, there should be consideration always in preserving the original design codes. The ideas that I have been taught is while it might be inconsistent to use the codes like that, there is no need to be “afraid” in both using general codes for future reference and bending the original design a little to improve the programming process. Learning the ideas from this blog shows me that for future practice, I should try to find features implemented in designs and trace down codes that give a complexity on the urge of repeating itself. That way, I can try to get the simple thinking of identifying problems without having to recreating codes like that. With this knowledge, I hope to assist others with great analyzing and fix codes better than I used to.

-Dennis Tran

 

Link to blog: http://www.bfilipek.com/2012/11/design-smells.html

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.