From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to benderson’s blog, this week we are going to discuss an apprenticeship pattern discussed in the Apprenticeship Patterns book called “Breakable Toys”. This apprenticeship pattern discusses trying to find ways to learn when your work environment doesn’t allow failure to occur even though failure is key in learning in computer science as we learn from our mistakes most of the time and find solutions to fix them. This environment doesn’t allow the worker to learn which really impedes the knowledge that a computer scientist can gain. The solution that the book provides to fix this problem is doing simple at home projects that will help you learn and keep your brain thinking as a computer scientist would. Some examples of projects that you could do were making your own calendar from scratch, making a wiki, or an address book. They suggest making your project something that is useful to your everyday life and will improve your skills as an apprentice. The reason you want to build something is to learn from it and learn new things while creating your project that will make you a better computer scientist.

I’m glad I picked this apprenticeship pattern first because I can relate to this as one of my biggest fears of when I get a job is “what if I fail at doing something? Am I going to get fired after one mistake?”. Failure is a big part of learning, lots of scientists, especially some computer scientists, have made some mistakes and that has led them to create bigger and better things and makes them better at their profession. No one in this world is perfect and will get something right 100% of the time but that doesn’t mean that you can get a lot things wrong and expect to have a job at the end of the day. Creating projects and working solo on your own objectives will make you learn and influence you to keep going and figure out how to get over certain obstacles. Problem solving skills is huge in work environments as finding the solution as quick as possible is always key in a job and the solutions that the pattern reading provides are great in making you better at that specific trait. “Breakable Toys” is a great title for the pattern as that is exactly how it is, as a child you play with a toy and figure out what it can do and the many ways you can use it and it’s like you grew up and you’re translating that exact principle to computer science and what you can create with your knowledge. Thank you for joining benderson’s blog this week!

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

Sure, software can be of the most useful tools to people trying to get their job done. But if you make mediocre software, it can just cause stress and annoyance to the person trying to use it.

So why test your software? Why should you make it as easy as possible to use?  A blog on SmartBear talks about 5 main reasons why software quality assurance is so important. It can be found here: https://blog.smartbear.com/sqc/5-reasons-why-software-quality-matters-to-your-business/

This blog really drives home the importance of software quality from a business view. Obviously, we all know the saying “quality over quantity”, so it should not be a big surprise that the quality of a company’s product should be excellent. The blog isn’t very long but I picked it because it makes very good points about how creating good software effects the people around.

The main five subsections of the blog are predictability, reputation, employee morale, customer satisfaction, and bottom line.

Predictable software is one of the most satisfying things to come across as a coder. It should do this, and it does just that. Nothing better than that! Software that is predictable is easier to use and people have a much better experience using the software. I like that the blog says “do it once and do it right” but don’t expect to get it right the first time. Re-work it even if it works, just to make it better! This leads to a good reputation.

Reputation is important to who you are and it sure is just as important in software quality. You want to have a good reputation so you have to put in the work to make sure the software works as it should. You could have hundreds of good quality programs and one really bad one and still have a bad reputation, just because of that one bad program.

Think about the people using your software! Do you really want them to have to keep restarting it because it won’t load? I know I have a few programs at work that I try to avoid at all costs! Using programs like these cause people to hate you, yes you, the creator. Which is why the blog talks about “Employee Morale” and how good quality makes everyone that much happier.

Happier people means less work in the long run. Do it right and be organized and your customers will be satisfied with your software. If they are unsatisfied, that means you have to fix things and make it better, OR run your reputation into the dirt! Test your code so much it hurts.

The bottom line is that your software quality NEEDS to be good. All of these things above come from well-tested code. So if you are reading this and you are studying testing like me, just remember that whatever you do, don’t slack on testing, it is one of the most important part of creating software!

 

 

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

I am required to read quite a bit of code written by other people, and over the years I’ve found that there are some problems that tend to recur again and again. The idea with this blog entry is to write up some tips , in the hope that it can help people out there who struggle to write clean code.

These are the tips for clean coding or good coding.

 

Keep classes small

So far you’ve created a few classes. After generating getter/setter pairs for even the small number (by the standards of a real-world Java class) of attributes, the Person class has 150 lines of code. At that size, Person is a small class. It’s not uncommon (and it’s unfortunate) to see classes with 50 or 100 methods and a thousand lines or more of source. Some classes might be that large out of necessity, but most likely they need to be refactored. Refactoring is changing the design of existing code without changing its results. I recommend that you follow this best practice.

In general, a class represents a conceptual entity in your application, and a class’s size should reflect only the functionality to do whatever that entity needs to do. Keep your classes tightly focused to do a small number of things and do them well.

Keep only the methods that you need. If you need several helper methods that do essentially the same thing but take different parameters (such as the printAudit() method), that’s a fine choice. But be sure to limit the list of methods to what you need, and no more.

Name methods carefully

A good coding pattern when it comes to method names is the intention-revealing method-names pattern. This pattern is easiest to understand with a simple example. Which of the following method names is easier to decipher at a glance?

• a()
• computeInterest()

The answer should be obvious, yet for some reason, programmers have a tendency to give methods (and variables, for that matter) small, abbreviated names. Certainly, a ridiculously long name can be inconvenient, but a name that conveys what a method does needn’t be ridiculously long. Six months after you write a bunch of code, you might not remember what you meant to do with a method called compInt(), but it’s obvious that a method called computeInterest(), well, probably computes interest.

 

Omit needless code!

It’s quite common to find code that’s commented out, but still hanging around. This is mainly bad because it bloats the code unnecessarily. People seem to do this because they want to have the possibility to bring the code back, either because they are writing an alternative they are not sure about, because they don’t dare to delete it. However, in nearly all cases there is no real reason to keep such code around. You should be using version control, and that means you could always find any deleted code again.

Also, since this code is no longer compiled or executed there is no real difference between commenting it out or deleting it. You’ve still made the change. The difference is that now it’s quite likely that this code will slowly move out of sync with the code around it, so that by the time you find you want it again it will no longer work. That actually makes the code dangerous, because it tempts you to include code without understanding what it does. (If you really understood it you could retype it quite quickly even if it was deleted.)

Of course, commenting out code while you are working on the code is fine. I do that a lot. However, I never check in code that is commented out, and whenever I find such code I delete it, without asking anyone or telling them. If they wanted the code they shouldn’t have commented it out. And it will be in the version history, anyway.

I chose this topic because i want to write code in a clean, efficient and faster way. I also chose this topic because since we will be studying it in the CS-343 class , why not learn ahead to get much more understanding on it.

Even though i knew some things about clean coding, i learned a lot. Some stuff i didn’t know where there. With these materials i have gain from other blogs or website added to my little knowledge of clean coding , i hope it will help me develop better coding in a clean, efficient and faster way.

 

I got the above information from this link ::: https://www.ibm.com/developerworks/library/j-perry-writing-good-java-code/index.html 

And

http://www.garshol.priv.no/blog/105.html

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.