Month: January 2015

by

Angular Basics using Plunker

Hi Friends,

I was just trying http://plnkr.co and i found the same really interesting. I was just trying my hands with few angular basics and found the tool really cool, hence thought to share the same.

Below example is just a databinding using ng-controller.

Below example just explains how to use $http service. Here, i have just used my git profile to make an http call.

Below is the same example what we have seen above but with a little tweak; this time with ng-module.

However, this is not a angular series just a refresher. Angular series is already shared.

Thanks,
Rahul
Happy Coding

by

5 Coding problems you should avoid to write elegant code

Hi Team,

First of all Happy New Year to all my readers. Today, I’m going to talk about some basic problems which developers usually commit while writing the code. Generally, it happens because of last minute changes what you do in your code just to meet the deadline or fix some unforeseen errors.

doctor

  • Complex models:-

    The first step is understanding why your code is hard to read. Because you are writing to solve a problem statement. In order to solve any problem we first need to form a model of that problem. Think of this as the intent of your program. Next you need to form a model of a solution that will achieve your programs’ intent. Lets call this the semantic model. Never confuse the intent of your program with your solution to that intent. Eliminating as much of this accidental complexity as possible is crucial if you want easy to maintain, simple code. The problems we are trying to solve are complex enough. Don’t add to it if you don’t have to.

  • Poor translation of understanding into code:-

    Once you have understood the problem, it needs to be properly labeled with Nouns so that you can identify the same while starting to design the solution. You should always write code with proper labels and comments so that others can understand the piece easily.

  • Single responsibility principle (SRP):-

    The SRP is one of the core Object Oriented Design Principles and ties in with good class and variable names. The idea behind using SRP is your class should stick to job thats it. you should overdo your class otherwise again you need to do refactoring at later point of time.

  • Class Design:-

    I always choose my class names as descriptive ones which we identified during user story discussion.In Domain Driven Design, it is extremely important that you stick to proper class designs and attributes you are going to include in that. Even if you don’t buy any design pattern approach you should be very careful about class structure and names.

  • Variable, parameter and method names:-

    At many places i have seen people write their method names very generic like Process,Post,Get,…etc. This is not at all a good practice, this will confuse you also while debugging or troubleshooting. Please be descriptive about your Methods like FetchMovie or FetchMovieReview. This way you can cut down your analysis effort if you are doing at later point of time. Everybody loves clean code but very few makes this practice.

Thanks,
Rahul
Happy Coding