Freshers and Software Companies (1.0)

The Software Industry is cruel. Freshers think that after completing graduation they will join some office and code there which will be satisfactory. Is it actually? No, definitely not. What will you develop? Why the company should spend money after you? Knowledge might be power but Time is Money.

In 90% of cases, you have to modify and extend existing projects. You might think, “But How can I edit this large code that has already been coded this far? This is not my code. I am not getting anything out of this code! This code should be rewritten. Who wrote this code? Does he have any idea?”.  Trust me that won’t work.

That is why good companies recruit good candidates who have the patience to understand a particular scenario and have a good grasp of the basic.

Some rules that should be maintained strictly during Software Development / Coding

Each project has its own internal architecture after knowing the business module of that project. I will not focus on these things rather I want to focus on coding styles. It is applicable to any language existing in the world.

  1. We should try our best not make things difficult for the upcoming developers. Because however good you might be you are always replaceable.  There is a saying,  “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”– Martin Fowler.
  2. The codes should always be Intention Revealing. Suppose, I want to send an email. I may write the block with some lines of code in a function. So what about the name of the function? I can name the function like the following:
     abc(param1, param2, param3){ .. } 

    What if I would have written like this:

     sendEmail(from,to,messagBody){ .. } 

    Sensible? yes definitely! I think a 5th grader would have understood the later one easily.

  3. A function’s name should be Verb and at the same time, these names should definitely not be funny names. Try to put exact what your trying to do. Bad naming convention:
     object.whack(){ .... ; } 

    Good naming convention:

     object.kill(){ .... ; } 
  4. A repeatable variable name should be avoided. Suppose, You declare a String as follow in java
     String strTitle = "My Blog"; 

    This is irrelevant. You are declaring string twice. You should edit to

     String title = "My Blog"; 
  5. Variables, Function Names should be Pronounceable and Readable. Suppose, I want to find whether a record already exists or not in DB by its id. I may write the variable name as
    recordavailableindb = repository.find(id); 

    It is difficult ot read the variable at a first glance. Isn’t it? What if I would have written

     recordAvailableInDb = repository.find(id); 

    Yes, it is easier to read. Camel case is a great way to manage your codes.

  6. A large function should be moduled into smaller functions. Suppose, You want to upload a picture in your server. Take an example of Facebook. You can upload profile pictures, cover pictures and post pictures in statuses. Let me module them into smaller parts as following:
  • Upload type of Image: It might be the cover image or profile picture
  • Extension of the image: Suppose you want users to upload only .jpg and .png images to make your life simpler.
  • Image Size restriction: you should set a minimum height, width or overall size (ex: in MB) for an image to be uploaded.
  • Image write and quality maintenance: All of your images should be saved in your server for later use. What about the size of the images? During upload, a user can upload a 10MB profile picture and what if thousands of users do the same? That’s why, you also need to maintain the image quality as well as the size using Image Rasterization. Otherwise, your server’s loading time will be huge and the user will have to wait for a long time.

The above points can be coded in a single function. Or you can divide your long function to those above mentioned points by just passing parameters sequentially. What if you need to change a small part of the code in the future? You can just edit a portion of the written small functions and your hassle is lesser.