My teammate and I are currently finishing up our Angular “Blackjack” project. The program seems to be running fine and doing everything we originally intended it to do. Now comes the important task of “cleaning up” our project. Examples of this are going through our program, rectifying any remaining bugs, and fixing any potential style inefficiencies within our code.

In order for us to clean up our code as efficiently as possible, I feel it is a good idea to brush up on ideal Angular style practices. By doing so, we can ensure our code is up to par with Angular standards. There is an excellent Angular Style Guide article that I strongly feel can help us in our “clean-up” task.

The guide is an article directly from the official Angular website. It gives examples of various “Angular style” coding techniques. Each is followed by a suggestion of whether the developer should (“do”) follow the example style, “consider” the style, or abandon the style (“don’t”) for a better alternative. I will outline certain styles mentioned in this article. I will also offer my personal takeaways on these style suggestions, as well as the Angular article in general.

General Naming Guidelines

Angular asserts the best practice is to name project files in a way that specifically identifies the function of that file. Each should follow the standard pattern of ‘feature.type.extension’. For example, our Blackjack project has a “player hand” component. Based on the suggestions of this article, we felt it was most appropriate to name each of the “player hands” companion files as ‘player-hand.component.ts’, ‘player-hand.component.html’, etc. Furthermore, the article suggests that each component, service, etc, along with their companion files, should all be located within the “src” folder in their own sub-directory. When going through the process of “cleaning up” our code, we will ensure that each section (service, component, etc) are in the folders they ought to be, in accordance with Angular standards.

Single Responsibility Principle (SRP)

The Angular article suggests that a project should follow the SRP whenever possible. Based on everything I’ve learned in the Computer Science program so far, it is always best to have a function to do just “one thing” as clearly and efficient as possible. Thus I feel it should follow that in Angular, we should only have the code for one component per file, one service per file, and so on. Though it is technically possible to write code for multiple types within one file, according to this article, it is bad practice to do so. When looking over our code, we will ensure we have all of our components, services, etc within their own appropriately named files.

The Angular article goes in great detail of good Angular style practices, and which ones to avoid. We have referenced this article a great deal during our project, thus I feel it directly relates to this course. I am sure this article will be useful during my professional career when working on additional Angular projects.

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

We’ve recently conducted “group code reviews” on a given project, where the goal was to identify any issues and/or bugs we could find within the project’s code. I found this to be a good exercise because I will likely be doing many code reviews during my professional career.

My ultimate goal regarding code reviewing at this point is to learn how to do it as efficiently as possible. Sara Tansey has a great blog on the topic, entitled 7 ways to up-level your code review skills. She identifies several strategies in particular that she feels are important when reviewing code. I will outline a few of these strategies that I found especially relative to our course’s content, along with my personal thoughts and takeaways.

“Prioritize the goals of code reviews with your team.”

I feel this is an important topic which I am glad Sara mentions in her blog. The main idea here is to make sure your team is up to speed with what each individual team member should be looking for. One example I can think of is the following: perhaps “Person A” could be looking specifically for bugs while “Person B” concentrates on code style. Then perhaps each team member can go through the code together and see if there is anything they have missed.

“Run the app and try playing with the features.”

Sara brings up potential difficulties of trying to perform effective code reviews solely on the basis of reading the code. I agree with her stance that code reviewers ought to run the program and “play with” the features as well. I believe this is a good strategy because seeing the program in action may provide some clarification on what the code is doing, and what it is intended to do.

“Always give approval, unless you can prove that there is a bug.”

I believe what Sara is referring to here is a code reviewing team that has the responsibility of either approving or denying a developer’s request to continue with production. Giving approval to proceed barring the existence of bugs makes sense to me. There doesn’t seem to be much of a reason to halt production on the sole basis of “less than optimal code style” in my opinion. I feel if the code works, certain style inefficiencies can easily be addressed based on the feedback of code reviewers.

I enjoyed reading Sara’s blog and feel she brought up many good strategies to conduct efficient and high-quality code reviews. I especially like her suggestion that we ought to be running and going through the apps themselves, rather than just reading the code alone. Running the program might give us some context that we may have missed if we relied on simply reading code lines without actually seeing the app in action. During my professional career, I will adhere to Sara’s suggestions while conducting code reviews for given projects. I will run through the actual program as well.

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

So for this week, I have decided to read another blog and that is “3 Principles to simplify your life as a developer” from the iTexico Blog. The reason I have chosen to read this blog is because I usually do not get a clear grasp of these kinds of principles. With getting a clear understanding of these principles, they will help in applying code, simplicity, and managing the overall process.

As the title applies, this blog post basically goes over 3 principles that are basic but powerful that will make life as developers easier and they are KISS, YAGNI, and DRY. The first principle KISS stands for Keep It Simple, Stupid and the meaning of it is straightforward. The simpler the code is, the simpler it will be easier to maintain in the future. This means that according to the author’s advice, developers should avoid using fancy features from the programming language they are having it in on. It does not mean developers should not use these features, it is to say only use them when there are perceptible benefits to solving a problem. Second principle YAGNI stands for You Aren’t Gonna Need It and the meaning is rather related to programming the first time. We do not want to waste time coding extra features that might not fit to what is needed or in the worst-case scenario, it will not be used. So from the author’s advice, when there is an unexplained anxiety to code extra features, take a deep breath and see the pending work at the moment. The third principle DRY stands Don’t Repeat Yourself and the meaning is clear to understand. We must try to maintain the behavior of a functionality of the system in a single piece of code. This means to keep it in a steady pace to avoid redundancy.

Based on the contents of this blog, like the concept of KISS, I would say this was simple and easy to read. The author gave the meaning of the principle, explained the origin of it, and advice on how to apply it while programming. What I did before to try to understand these principles while coding is that I try my best to not write down a method twice or an extra class unless needed.

What I learned from this blog about the principles is that DRY should be not used all the time in the life as a developer. The idea I got from this blog is that while DRY is a good principle to follow, it will sometimes when violated lead to a solution which is called WET or Write Everything Twice and that is a bit of time spent. For future practice, I should try to apply the KISS and YAGNI principles a bit more while writing down code as it will not only save from being overwhelmed on how the code works but also others that can benefit from it.

Link to the blog: http://www.itexico.com/blog/bid/99765/software-development-kiss-yagni-dry-3-principles-to-simplify-your-life

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.

Last week, I wrote my blog on Code Reviews. This week I am writing about how much time we should be spending during Code Reviews. I found an interesting article titled “Don’t Waste Time on Code Reviews” on DZone written by Jim Bird.

According to the article, research shows that reviewers find far more maintainability issues than defects (a ratio of 75:25) and spend more time on code clarity and understandability problems than correctness issues. There are a few reasons for this. Finding bugs in code is hard. Finding bugs in someone else’s code is even harder. In many cases, reviewers don’t know enough to find material bugs or offer meaningful insight on how to solve problems. Or they don’t have time to do a good job. So they cherry pick easy code clarity issues like poor naming or formatting inconsistencies. But even experienced and serious reviewers can get caught up in what at first seem to be minor issues about naming or formatting, because they need to understand the code before they can find bugs, and code that is unnecessarily hard to read gets in the way and distracts them from more important issues.

Code reviews add to the cost of development, and if you don’t do them right they can destroy productivity and alienate the team. But they are also an important way to find bugs and for developers to help each other to write better code. So do them right. Don’t waste time on meetings and moderators and paper work. Do reviews early and often. Keep the feedback loops as tight as possible. Ask everyone to take reviews seriously – developers and reviewers. No rubber stamping, or letting each other off of the hook. Make reviews simple, but not sloppy. Ask the reviewers to focus on what really matters: correctness issues, and things that make the code harder to understand and harder to maintain. Don’t waste time arguing about formatting or style. Make sure that you always review high risk code and high risk changes. Get the best people available to do the job – when it comes to reviewers, quality is much more important than quantity. Remember that code reviews are only one part of a quality program. Instead of asking more people to review code, you will get more value by putting time into design reviews or writing better testing tools or better tests. A code review is a terrible thing to waste.

I would say that the title was somewhat misleading though. I wish the title was less misleading, though – it’s easy to read as “Don’t do code reviews,” which isn’t what the post was saying. I think the title was either poorly worded or it was written that way intentionally as click bait. I think a better title would have been “Don’t Waste Time During Code Reviews”. I was spending lots of time reviewing code that a static code review tools can do. Form now, I would rather use tools like FindBugs and PMD which uses static analysis to look for bugs.

Source: https://dzone.com/articles/dont-waste-time-code-reviews

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.