Category Archives: Week 6

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

So, we meet again with what makes code stink. As I mentioned in my blog last week, this is a continuation from the same post that I covered last week, as there were simply too many points I wanted to hit upon to fit in one post. For those who missed last week’s post or can’t remember, smelly code is basically trends in code that commonly known to cause problems. The goal is to make sure you code doesn’t stink when you are done with it, or you’ll regret it later down the line.

The next item on the list are comments. Comments can be great. They provide insight into how the developer was thinking, why they designed it the way they did, what is going on in that quadruple nested for-loop below the comment, etc. The thing is, if you are really a good developer, an argument can be made that the code can speak/explain itself. Personally, I’ve always found comments useful and insightful, but the point here is that your code should not be so ambiguous or so complicated that you need an entire paragraph just to explain what is going on. While I don’t necessary agree that there should be no comments at all, I do agree that comments should be kept to a minimum, and if you can’t, something is wrong with your code.

Pressing further down Jeff Atwood’s list of smelly code we run into the category of duplicate code. Please don’t duplicate your code. The reasons are self-explanatory, but I will reiterate: it is bad, wasteful, and inefficient. If you need to perform a task more than once, put it in a function, simple as that. You’ll save everyone a few headaches. Similarly, he mentions dead code. That is code that is sitting in there, wasting its life away as a comment or performing some task is never used, wasting resources. There should never be a need to leave unused code. The wonderful invention of version eliminated the need to leave old code sitting in a program.

The last item on his list that I want to touch upon is the bad habit of making items public when shouldn’t be, or as he calls it, indecent exposure. There should be a strong effort to make everything is as private as possible, and there should be a damn good reason if it not private. Exposing the internals of a class is dangerous and unwarranted. Unless something absolutely has to be public, it should stay private.

There were items on Atwood’s list that I felt were unnecessary or didn’t completely agree with, but overall, I found his list of code warning signs useful and brought up many valid points. As developers we want our code to be clean, efficient, and easy to read. I feel that going through this list would certainly help anyone reach that goal. A lot of the items on the list are thing experienced developers should know better than to try anyhow, but it can’t hurt double check when you are done. I know I certainly will try to run through his list in the future.

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.

Software Testing Life Cycle

This week I looked up software testing blogs. While searching the web I found this one blog called mallow-tech. there was this one blog post called “Software Testing Life Cycle” written by Periannan, a test engineer for Mallow Tech. In this blog it talks about what software testing life cycle (STLC) is. Software testing talks about the testing process that has specific steps to be done to make sure that the code meets the quality standards. For many companies they have different phases for STLC however the base of it is the same for every company. STLC usually has six phases. Requirement Analysis, Test Planning, Test Case Design, Test Case Execution, Re-Testing and Regression, and Final Testing and Closure. In the Requirement Analysis phase this is where the team talks to the client about what they want and talks to the team of developers about what parts are testable and how they would run those tests. The next phase is test planning which they see what kind of they are going to use to test out the code. Number three is test designs this is where test cases are created according to the specifications for the project. Next is the test execution. Here they execute the tests in logical sequences with specific test data. Next is the retesting and regression testing phase by this time the tests would have been done and the bugs would have been reported. The team would then fix those bugs and then run the test again to make sure everything was fixed. Lastly final testing and closure is where the final parts of the STLC is completed and they start to send it out into the public to find out if the code works.

This blog was very helpful for me because I did many blogs about different tests that we have to do but this blog talks about the process of testing. With this blog I think it is super helpful as an add on to my other blogs. In the real world we are not going to just run tests one right after another. We need a plan on what to do and when to do it. This shows me that everything in the computer science world is not just doing code and making sure it works it is all about doing things in steps just like how we write code it should be neat and organized and planned.

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.

The Clean Coder 11 & 12 Week 6

The first part of the reading talks about pressure in the work place. Commitments are a big deal in a professional environment and while you should try to avoid them as best you can sometimes other people make them for you. You are not responsible for these commitments if you did not agree to them so you should not stress over them. Keeping everything clean will help reduce stress, so make sure to take the time to make sure your code is clean. I know that if I start coding quickly and dirty that it becomes a mess and I get stressed out. Don’t be too proud to get help, if you’re running behind find a co-worker that is willing to help you.

The second section talks about collaboration, it’s a very important part of programming, we can’t do it all ourselves sometimes. When working with a team do not “own” your code, make the code accessible available to change by anyone in the team. A lot of programmers did not get into their field to work with people, quite the opposite, most did because they don’t enjoy working with people. Unfortunately there is no way to avoid this, working with other programmers and clients cannot be avoided.

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.