DEV Community: Naveen

[MicroArticle] [JavaScript] Variable Declarations

Naveen — Sun, 17 May 2020 08:48:23 +0000

MicroArticle is a bite-sized learning technique that focuses on learning just one key objective, applying them practically and feeling accomplished.

Well, what's in it for me and why do I care?
Turns out that, attention spans are getting shorter and the learners want to be engaged, entertained, motivated to learn something new and be able to see improvements

Motivation behind why I started this initiative:
I have always been passionate about writing and I am struggling to find time to write lately for the past couple of years and the greatest hurdle I am facing is going from inertia to mobility.

I had to come up with some strategies to resume my "habit" of writing. Having said that, I believe that most of our lives are governed by our habits. If you want to build a new habit, make that habit as easy to adopt as possible. Hence my idea of writing an almost ridiculously tiny article as possible - I ended up naming it as "MicroArticle". Picking an easy goal eliminates any perceptions of difficulty and is hardly daunting enough to make you feel fatigued.

In this MicroArticle, we will discuss on how to declare variables in JavaScript and what is the difference between different keywords var, let and const

What are Variables?
They are just containers for storing data values - you can place data into these containers and then refer to the data by naming the container. Before using a variable in JavaScript, it must be declared.

Keywords to declare Variables:
Before JavaScript ES6 introduced, the only keyword available to declare a variable was the var keyword. Now there are 2 more additions to it - let and const

Why these 2 new keywords are introduced?
This is to allow programmers to decide scope options for the defined variables.
var - Function Scope
let and const - Block Scope

What is a Function Scope?
Refer to the below example - the variable i which is defined in the for loop is scoped even outside the for loop within the function. That's the reason why the console output till the number 5 (See the result tab)

What is a Block Scope?
Variables declared with the let keyword can have Block Scope - Variables declared inside a block { }. As a result, the Below code would throw an error since the variable i is accessed outside the block of for loop.

function foo() {
  for (let i = 0; i < 5; i++) {
    console.log(i);
  }
  console.log(i);
}

foo();

What if I have the same variable say x defined both inside and outside the block scope?

var x = 1;
{
  var x = 2;
}
// What's the value of x here?

The above code will have the value of variable x as 2 (modified)

Try to guess what's the value of variable x in the below code snippet?

var x = 1;
{
  let x = 2;
}
// What's the value of x here?

If you guessed it right, the value of x outside the block would still be 1.

Best Practices

Declare variables at the top of each script or function - your code looks much cleaner and it makes it easier to avoid unwanted re-declarations
Initialize variables when you declare them - again, your code looks much cleaner and it provides a single place to initialize variables instead doing it all over the place
Use let if you think that the value of the variable is intended to get modified, else use const
Treat numbers, strings, or booleans as primitive values and not as objects - declaring as objects have performance impacts and side effects

Let me know what you all think about my initiative. The article might seem too trivial or basic for many of you here - but my idea is to get myself started with something small and also keeping my point on short attention span in mind.

Introduction to functional programming with C#

Naveen — Sat, 22 Apr 2017 11:37:55 +0000

It is no surprise that one of the biggest challenges in the enterprise software development is complexity. Change is inevitable. Especially when a new feature is introduced that adds complexity. This might lead to difficulty in understanding and verify the software. It doesn’t stop there, it increases development time, introduces new bugs and at some point, it is even impossible to change anything in the software without introducing some unexpected behavior or side effects. This may result in slowing down the project and eventually lead to a project failure.

Imperative programming styles like object oriented programming have capabilities to minimize complexity to a certain level when done right by creating abstractions and hiding complexity. An object of a class has certain behavior that can be reasoned without caring about the complexity of the implementation. Classes, when written properly, will have high cohesion and low coupling where the code re-usability is increased while complexity is kept reasonable.

Object oriented programming is in my blood stream, I’ve been a C# programmer most of my life and my thought process always tends to use a sequence of statements to determine how to reach a certain goal by designing class hierarchies, focusing on encapsulation, abstraction, and polymorphism that tend to change the state of the program which actively modifies memory. There’s always a possibility that any number of threads can read a memory location without synchronization. Consider if at least one of them mutates it that leads to a race condition. Not an ideal condition for a programmer who tries to embrace concurrent programming.

However, it is still possible to write an imperative program by writing a complete thread-safe code that supports concurrency. But one has to still reason about performance, which is difficult in a multi-threaded environment. Even if parallelism improves performance, it is difficult to refactor the existing sequential code into parallel code as the large portion of the codebase has to be modified to use threads explicitly.

What’s the solution?

It is worth to consider “Functional programming”. It is a programming paradigm originated from ideas older than the first computers when two mathematicians introduced a theory called lambda calculus. It provided a theoretical framework that treated computation as an evaluation of mathematical functions by evaluating expressions rather than execution of commands and avoiding changing-state and mutating data.

By doing so, it is much easier to understand and reason about the code and most importantly, it reduces the side effects. In addition to that, performing unit testing is much easier.

Functional Languages:
It is interesting to analyze the programming languages that support functional programming such as Lisp, Clojure, Erlang, OCaml and Haskell which have been used in industrial and commercial applications by a wide variety of organizations. Each of them emphasizes different features and aspects of the functional style. ML is a general-purpose functional programming language and F# is the member of ML language family and originated as a functional programming language for the .Net Framework since 2002. It combines the succinct, expressive and compositional style of functional programming with the runtime, libraries, interoperability and object model of .NET

It is worthy to note that many general programming languages are flexible enough to support multiple paradigms. A good example is C#, which has borrowed a lot of features from ML and Haskell although it is primarily imperative with a heavy dependence of mutable state. For example, LINQ which promotes declarative style and immutability by not modifying the underlying collection it operates on.

As I am already familiar with C#, I favor combining paradigms so that I have control and flexibility over choosing the approach that best suits the problem.

Fundamental principles:

Having stated before, Functional programming is programming with mathematical functions. The idea is, whenever the same arguments are supplied, the mathematical function returns the same results and the function’s signature must convey all information about possible input it accepts and the output it produces. By following two simple principles, namelyâ€Š–â€ŠReferential transparency and Function honesty.

Referential Transparency:
Referential transparency, referred to a function, indicates that you can determine the result of applying that function only by looking at the values of its arguments. It means that the function should operate only on the values that we pass and it shouldn’t refer to the global state. Refer to the below example:


public int CalculateElapsedDays(DateTime from)
{
     DateTime now = DateTime.Now;
     return (now - from).Days;
}

This function is not referentially transparent. Why? Today it returns different output and tomorrow it will return another. The reason is that it refers to the global DateTime.Now property.

Can this function be converted into a referentially transparent function? Yes.
How?

By making the function to operate only on the parameters that we passed in.


public static int CalculateElapsedDays(DateTime from, DateTime now) => (now - from).Days;

In the above function, we eliminated the dependency on global state thus making the function referentially transparent.

Function honesty:

Function honesty states that a mathematical function should convey all information about the possible input that it takes and the possible output that it produces. Refer to the below example:


public int Divide(int numerator, int denominator)
{
   return numerator / denominator;
}

Is this function referentially transparent? Yes.

Does it qualify as a mathematical function? May not be.

Reason: The input arguments states that it takes two integers and return an integer as an output. Is it true in all scenarios? Nope.

What happens when we invoke the function like:

var result = Divide(1,0);

Yes, you guessed it right. It will throw “Divide By Zero” exception. Hence, the function’s signature doesn’t convey enough information about the output of the operation.

How to convert this function into a mathematical function?

Change the type of denominator parameter like below

public static int Divide(int numerator, NonZeroInt denominator)
{
    return numerator / denominator.Value;
}

NonZeroInt is a custom type that can hold any integer except zero. Now, we have made this function honest as it conveys all information about the possible input that it takes and the output that it produces.

Despite the simplicity of these principles, functional programming requires a lot of practices that might seem intimidating and overwhelming to many programmers. In this article, I will try to cover some basic aspects of starting with which includes “Functions as first class citizens”, “Higher order functions” and “Pure functions”

Functions as first-class citizens:

When functions are first-class citizens or first-class values, they can be used as input or output for any other functions. They can be assigned to variables, stored to collections, just like values of other type. For example:


Func<int, bool> isMod2 = x => x % 2 == 0;
var list = Enumerable.Range(1, 10);
var evenNumbers = list.Where(isMod2);

The above code illustrates that functions are indeed first-class values because you can assign the function ( x => x % 2 == 0) to a variable isMod2 which in-turn passed as an argument to Where (an extension on IEnumberable)
Treating functions as values is necessary for functional programming style as it gives the power to define Higher-order functions.

Higher-order functions (HOF):

HOFs are functions that take one or more functions as arguments or returns a function as a result or both. All other functions are First-order functions.

Let’s consider the same modulo 2 example in which “list.Where” does filtering to determine which number to be included in the final list based on a predicate provided by the caller. The predicate provided here is isMod2 function and theWhereextension method of IEnumberable is the Higher-order Function. Implementation of Where looks like below


public static IEnumerable<T> Where<T>
   (this IEnumerable<T> ts, Func<T, bool> predicate)
{
   foreach (T t in ts)  â¶
      if (predicate(t)) â·
         yield return t;
}

â¶ The task of iterating over the list is an implementation detail of Where.
â· The criterion determining which items are included is decided by the caller

The Where HOF applies the given function repeatedly to every element in the collection. HOFs can be designed to conditionally apply the function to the collection as well. I’ll leave that for you to experiment. By now you would have realized how concise and powerful Higher-order functions are.

Pure functions:

Pure functions are mathematical functions that follow the two basic principles that we discussed beforeâ€Š–â€ŠReferential transparency and Function honesty. In addition to that, Pure functions don't cause any side effects. Which means, it mutates neither the global state nor input arguments. Pure functions are easy to test and reason about. Since the output is dependent only on input, the order of evaluation isn’t important. These characteristics are very vital for a program to be optimized for parallelization, Lazy evaluation, and Memorization (Caching).

Consider the below example console application that multiplies a list of numbers by 2 and nicely formats that into multiplication table.


// Extensions.cs
public static class Extensions
{
    public static int MultiplyBy2(this int value)â¶
    {
       return value * 2;
    }
}
// MultiplicationFormatter.cs
public static class MultpilicationFormatter
{
    static int counter;

    static string Counter(int val) => $"{++counter} x 2 = {val}"; â·

    public static List<string> Format(List<int> list)
        => list
         .Select(Extensions.MultiplyBy2) â¸
         .Select(Counter) â¸
         .ToList();
}
// Program.cs
using static System.Console;
static void Main(string[] args)
{
     var list = MultpilicationFormatter.Format(Enumerable.Range(1, 10).ToList());
     foreach (var item in list)
     {
        WriteLine(item);
     }
     ReadLine();
}
// Output
1 x 2 = 2
2 x 2 = 4
3 x 2 = 6
4 x 2 = 8
5 x 2 = 10
6 x 2 = 12
7 x 2 = 14
8 x 2 = 16
9 x 2 = 18
10 x 2 = 20

â¶ A pure function
â· An impure function as it mutates the global state
â¸ Pure and impure functions can be applied similarly

The above code executes well without any issue as we are operating only on 10 numbers. What if we want to do the same operation for a bigger set of data especially when the processing is CPU intense? Would it make sense to do the multiplications in parallel? That means the sequence of data can be processed independently.

Certainly, we can use the power of Parallel LINQ (PLINQ) to get parallelization for almost free. How can we achieve this? Simply by adding AsParallel to the list.


public static List<string> Format(List<int> list)
=> list.AsParallel()
         .Select(Extensions.MultiplyBy2)
         .Select(Counter)
         .ToList();

But hold on, pure and impure functions don’t parallelize well together.

What do I mean by that? As you know that Counter function is an impure function. If you have some experience in multi-threading, this will be familiar to you. The parallel version will have multiple threads reading and updating the counter and there’s no locking in place. The program will end up losing some updates which will lead to incorrect counter results like below


1 x 2 = 2
2 x 2 = 4
7 x 2 = 6
8 x 2 = 8
6 x 2 = 10
4 x 2 = 12
9 x 2 = 14
10 x 2 = 16
5 x 2 = 18
3 x 2 = 20

Avoiding state mutation:
One possible way to fix this is to avoid state mutation and running counter. Can we think of a solution to generate a list of counters that we need and map them from the given list of items? Let’s see how:


using static System.Linq.ParallelEnumerable;
public static class MultpilicationFormatter
{
   public static List<string> Format(List<int> list)
   => list.AsParallel()â¶
      .Select(Extensions.MultiplyBy2)
      .Zip(Range(1,list.Count), (val, counter) => $"{counter} x 2 = {val}")â·
      .ToList();
}

Using Zip and Range, we have re-written the MultiplicationFormatter. Zip can be used as an extension method, so you can write the Format method using a more fluent syntax. After this change, Format method is now pure. Making it parallel is just a cherry on top of the cake â¶.This is almost identical to the sequential version except â¶ and â·

Of course, it is not always as easy as this simple scenario. But the ideas that you have seen till now will deploy you into a better position to tackle such issues related to parallelism and concurrency.

This article was originally posted in my Medium blog

How to write an object oriented program that doesn't suck

Naveen — Thu, 17 Nov 2016 03:50:41 +0000

It is fairly obvious that object oriented program has been used as a silver bullet in the modern day programming. Whether you are working as a technical architect or a computer science student, merits of OOP are highly regarded.

I have seen many computer programmers proudly proclaim “Yup, I designed my code in an object oriented wayâ€Š–â€ŠI have defined my data members as private, they can be only accessed through public methodsâ€Š–â€ŠI have created base classes and sub-classes that follow a hierarchyâ€Š–â€ŠI have created virtual methods in the base class that shares common behavior that can be used in derived classes.” Is that what object orientation is all about? There is definitely more to it.

First of all, we need to understand the purpose behind using object oriented programming. Apart from small throw-away programs that are written to perform a single task and run only once, complex software applications will always require more changes. Your source code needs a regular update either to add new features to the system or to fix bugs. Object oriented programming organizes your code to make the change easier. In addition to that, object oriented programming allows the breaking bigger and complex problems into smaller and reusable modules which provide a consistent method for managing the large code base.

Most of the programmers think that they understand the foundation of the object orientation. When it comes to applying it to real world applications, they struggle.

Most of us suck at object oriented programmingâ€Š–â€Šand that's okay. All it takes to become good at anything is to have patience, practice and a little faith in yourself. Object orientation is not only a programming technique but it is a shift in thinking which requires a lot of practice and good design.

How to practice?

I wrote an article about Procrastinating the procrastination in Medium where I explained how to start with something small. Trying to learn object oriented programming initially may look intimidating and overwhelming. Instead of over-complicating and trying to learn everything at once, try taking small steps at a time and try to understand the motive behind applying object orientated design to your code. By practicing how to design a system, you will start to get a natural feel of object relationships. Then, translate it to code. You will start seeing common areas that can be abstracted, modularized and other ways that will improve both your design and code.

How to figure out if my code sucks?

Most of our codes are not perfect in many ways and it will take ages to list all the possible flaws. However, I will list some of the most common and frequent mistakes and give some suggestions to fix them.

Adding more functionalities or responsibilities to a class that is not related. Consider the below example

class Account
{    
   public void Withdraw(decimal amount)    
   {        
      try        
      {            
          // logic to withdraw money       
      }        
      catch (Exception ex)        
      {            
          System.IO.File.WriteAllText(@"c:\logs.txt",ex.ToString());   
      }    
   }
}

Can you figure out the problem in the above code? Account class has taken additional responsibility of adding exceptions to the log file. In future, if there's a requirement to change the logging mechanism, the Account class needs to be changed. Well, this doesn't seem to be right.

Fix:

A class has to take only one responsibility and there should be only one reason to change the class. This can be fixed by moving the logging activity to a separate class which takes care of just logging exceptions and writing it to a log file.

public class Logger
{
   public void Handle(string error)
   {
       System.IO.File.WriteAllText(@"c:\logs.txt", error);
   }
 }

Now the Account class has the flexibility to delegate the logging activity to the Logger class and it can focus only on Account related activities.

class Account
{
   private Logger obj = new Logger();    
   public void Withdraw(decimal amount)    
   {        
      try        
      {            
          // logic to withdraw money       
      }        
      catch (Exception ex)        
      {            
          obj.Handle(ex.ToString());
      }    
   }
}

Consider there is a new requirement to handle different account types like savings account and current account. To cater to this, I am adding a property to the Account class called “AccountType”. Depending on the type of the account, the interest rate differs too. I am writing a method to calculate interest d on the account type.

class Account
{
   private int _accountType;

   public int AccountType
   {
      get { return _accountType; }
      set { _accountType = value; }
   } 
   public decimal CalculateInterest(decimal amount)    
   {        
      if (_accountType == "SavingsAccount")
      {
         return (amount/100) * 3;
      }
      else if (_accountType == "CurrentAccount")
      {
         return (amount/100) * 2;
      }
   }
}

Problem with the above code is “branching”. If there's a new account type in the future, again Account class has to be altered to cater the requirement which linearly increases the number of if-else condition to the code. Note that we are changing the Account class for every change. This clearly is not an extensible code.

Fix:

It is always a good practice to open the code for extension and close for modification. Can we try extending the code by adding a new class whenever a new account type needs to be added and inherit it from Account class? By doing so, we are not only abstracting the Account class but also allowing it to share common behavior across it's child classes.

public class Account
{
   public virtual decimal CalculateInterest(decimal amount)
   {
       // default 0.5% interest
       return (amount/100) * 0.5;
   }
}
public class SavingsAccount: Account
{
   public override decimal CalculateInterest(decimal amount)
   {
       return (amount/100) * 3;
   }
}
public class CurrentAccount: Account
{
   public override decimal CalculateInterest(decimal amount)
   {
       return (amount/100) * 2;
   }
}

Stay with me, this gets more interesting from nowâ€Š–â€ŠSay the business is coming up with new account type called Online Account. This account is having a good interest rate of 5% and holds all the benefits similar to the savings bank account. However, you cannot withdraw cash from the ATM. You can only wire transfer money. Implementation looks like below

public class Account
{
   public virtual void Withdraw(decimal amount)
   {
       // base logic to withdraw money
   }
   public virtual decimal CalculateInterest(decimal amount)
   {
       // default 0.5% interest
       return (amount/100) * 0.5;
   }
}
public class SavingsAccount: Account
{
   public override void Withdraw(decimal amount)
   {
        // logic to withdraw money
   }
   public override decimal CalculateInterest(decimal amount)
   {
       return (amount/100) * 3;
   }
}
public class OnlineAccount: Account
{
   public override void Withdraw(decimal amount)
   {
        throw new Exception("Not allowed");
   }
   public override decimal CalculateInterest(decimal amount)
   {
       return (amount/100) * 5;
   }
}

Now, consider that I wanted to close all my accounts with this bank. So, all the money from each account has to be taken out before closing the account completely.

public void CloseAllAccounts()
{
    // Retrieves all accounts related to this customer
    List<Account> accounts = customer.GetAllAccounts();
    foreach(Account acc in accounts)
    {
      // Exception occurs here
      acc.Withdraw(acc.TotalBalance);
    }
}

As per inheritance hierarchy, the Account object can point to any one of its child object. No unusual behavior is noticed during compile time. However, during the run-time, it throws an exception “Not allowed”. What did we infer from this? The parent object cannot seamlessly replace the child object.

Fix:

Let's create 2 interfacesâ€Š–â€Šone to process interest (IProcessInterest) and other one to process withdrawal (IWithdrawable)

interface IProcessInterest
{
    decimal CalculateInterest(decimal amount);
}
interface IWithdrawable
{
    void Withdraw(double amount);
}

The OnlineAccount class will only implement IProcessInterest while the Account class will implement both IProcessInterest and IWithdrawable.

public class OnlineAccount: IProcessInterest
{
    public decimal CalculateInterest(decimal amount)
    {
       return (amount/100) * 5;
    }
}
public class Account: IProcessInterest, IWithdrawable
{
   public virtual void Withdraw(decimal amount)
   {
       // base logic to withdraw money
   }
   public virtual decimal CalculateInterest(decimal amount)
   {
       // default 0.5% interest
       return (amount/100) * 0.5;
   }
}

Now, this looks clean. we can create a List of IWithdrawable and add relevant classes to it. In case if a mistake is made by adding OnlineAccount to the list inside the GetAllAccounts method, we will get a compile time error.

public void CloseAllAccounts()
{
    // Retrieves all withdrawable accounts related to this customer
    List<IWithdrawable> accounts = customer.GetAllAccounts();
    foreach(Account acc in accounts)
    {
      acc.Withdraw(acc.TotalBalance);
    }
}

Assume that our Account class is in super demand. Business is proposing an idea to expose an API which allows to withdraw money from different third party bank's ATM. We have exposed a web service and every other bank started consuming the web service to withdraw money. Everything sounds good till now. After couple of months, the business is coming up with another requirement saying that some other banks are requesting to set the withdrawal limit to this account from their ATM as well. No problem, raise a change requestâ€Š–â€Šit can be done easily.

interface IWithdrawable
{
   void Withdraw(decimal amount);
   void SetLimit(decimal limit);
}

What we just did was bizarre. By changing the existing interface, you are adding a breaking change and disturbing all the satisfied banks those were really happy consuming our web service to just withdraw. Now you are forcing them to use the newly exposed method as well. Not good at all.

Fix:

The best way to fix this is to create a new interface rather than modifying the existing interface. The current interface IWithdrawable can be as it is and a new interfaceâ€Š–â€Šsay, IExtendedWithdrawable is created which implements IWithdrawable.

interface IExtendedWithdrawable: IWithdrawable
{
   void SetLimit(decimal limit);
}

So, the old clients will continue using IWithdrawable and the new clients can use IExtendedWithdrawable. Simple, but effective!

Let's go back to the first issue we resolved where we added Logger class to delegate the responsibility of logging from Account class. It logs exceptions to a file. Sometimes it's easy to get the log files through email or to integrate it with some third party log viewer for ease of access. Let's implement this.

interface ILogger
{
    void Handle(string error);
}
public class FileLogger : ILogger
{
   public void Handle(string error)
   {
       System.IO.File.WriteAllText(@"c:\logs.txt", error);
   }
}
public class EmailLogger: ILogger
{
   public void Handle(string error)
   {
       // send email
   }
}
public class IntuitiveLogger: ILogger
{
   public void Handle(string error)
   {
       // send to third party interface
   }
}
class Account : IProcessInterest, IWithdrawable
{
   private ILogger obj;    
   public void Withdraw(decimal amount)    
   {        
      try        
      {            
          // logic to withdraw money       
      }        
      catch (Exception ex)        
      {            
          if (ExType == "File")
          {
             obj = new FileLogger();
          }
          else if(ExType == "Email")
          {
             obj = new EmailLogger();
          }
          obj.Handle(ex.Message.ToString());
      }    
   }
}

We wrote an excellent extensible codeâ€Š–â€ŠILogger which acts as a common interface to other logging mechanisms. However, we are again violating the Account class by giving more responsibility to decide which instance of the Logging class to be created. It is not the job of Account class to decide on object creation for logging.

Fix:

The solution is to “Invert the dependency” to some other class rather than Account class. Let's inject the dependency through the constructor of Account class. So, we are pushing the responsibility to the client to decide which logging mechanism that has to be applied. The client might in-turn depend on the application configuration settings. We may not worry about configuration level understanding in this article at-least.

class Account : IProcessInterest, IWithdrawable
{
   private ILogger obj;
   public Customer(ILogger logger)
   {
       obj = logger;
   }
}
// Client side code
IWithdrawable account = new SavingsAccount(new FileLogger());

If you have closely paid attention, you might have easily guessed that all these suggested fixes are nothing but the applications of SOLID principles of object oriented design. I will leave it to you to explore and analyze how exactly I applied every aspect of these design principles to the code.

If you believe like I do, that the object oriented programming is a shift in thinking, kindly share this article so that others can learn from it.

This article was originally posted in my Medium blog

Hi, I'm Naveen

Naveen — Thu, 17 Nov 2016 03:10:44 +0000

I have been coding for more than 7 years.

You can find me on Twitter as @k_nav

I live in Singapore.

I mostly program in these languages: C#.

I am currently learning more about Object oriented programming, dot Net Framework, Windows presentation foundation, SQL, Agile methodologies.

Nice to meet you all.