goodCode

All of us at some point would have asked this question to ourselves as to what does it take to write Good Code?  Yes, there are lot of static code analysis tools which gives us a measure of the quality of code to a decent degree.  Those are only reactive measures and sometimes it’s too late depending on the deadlines.  So, what does it take to write Good Code the very first time?

I consider writing code is an Art and one needs to practice to get good at it. It’s like the art of Painting, a well “done” Painting conveys message/s. It also identifies and many a time defines the personality of the Artist.  The exact same thing is true for Code as well, it conveys message/s and also identifies the personality of the person writing the code.  Hard to believe? Here are few insights that I observed, I am not being judgmental (and cannot be) about the patterns and the respective analysis that I am going to discuss, but they sure do convey latent message/s and also helps identify the personality of the author to a decent degree, at least it worked for me over the last 10+ years.  Please note that there are exceptions and the observations are strictly based on my experience and is not an attempt to generalize. The moment the word “person” comes into picture, it comes along with lot of other factors and hence this segment of this Post needs to be taken with not just a pinch but a decent amount of salt J

The Intent is, as one advances in one’s career and reviews various flavors of code, one should be able to map the author of the code into one of the recurring sets or patterns.

Below are a few patterns I observed at a very broader level and the respective analysis:

Pattern-1

Some authors declare:

  • Variables as: nxtPtr, istru, itmNumbr
  • Method Names as: getAvg(..),  cmputLCM(…) etc.
  • Class Names as: AvgCalclator, InptMgr

Names just convey the functionality and to the point comments in the code with no extra lines, on an average they give a line or maximum two.

Based on my observation, these are folks who have good aptitude, who give quick output with medium to decent code quality. Bright chance that they are quick learners. Sometimes they are really hard to deal with.

 Pattern-2

Some authors declare:

  • Variables as: nextPointer, isTrue, itemNumber
  • Method Names as: getAverageFrom(…), computeLCMFrom(…)
  • Class Names as: AverageCalculator, InputManagerSingleton

Very well defined names of and give detailed information while commenting the code and if they think it’s relevant the comments could run over a few lines.

Based on my observation, these are folks who always try to understand things too deep, the quality of code will be to the best to their abilities, they take time but aim for perfection, may not be able to crack aptitude tests as they think the answer carefully the second time to make sure it is correct, they think twice before making decisions. Most of the times they are very easy to deal with.

Pattern-3

Some authors declare:

  • Variables as: np, it, in
  • Method Names as: gtAg(…), cptLcm(..)
  • Class Names as: AvClac, InpMgr

Names barely imply the functionality and sometimes are ambiguous. Most of the times none or minimal code commenting.

Based on my observation, these are folks who just get the code working (Code Monkeys as opposed to Engineers) and miss the basic Engineering principles, code quality is a concern, may not be able to crack aptitude tests, lack seriousness and typically needs hand holding.

Similarly Design trade-offs, applied design patterns, average length of methods, average cyclomatic complexity etc. are all various patterns that come in handy to identify the personality of the author.

I normally get such information while I do code reviews and get a grasp of the person I am dealing with and as my interactions proceed and looking at more code from that individual, I keep tweaking my perceptions and identify an optimal approach (strategy) and means of communication with the author and that worked quite well so far.  This comes in handy especially when we deal with individuals who do not speak much or if we do not have good rapport with the individuals for all good reasons, or if the teams are too big to know each other and as we do peer reviews (across teams) etc.

 Peek into the Future 

All such patterns could be given to a Machine Learning Algorithm, train it and get useful information (may be a personality coefficient) using various code attributes from the code written by authors bearing different personalities. Then given a code snippet of a new author we could predict (the personality coefficient) if the current author could be a good fit (if the new members personality coefficient fall in the range of the current team’s coefficient range) into the Team which has various converging attributes and personalities. Now, that’s leveraging Technology to fix Technology – self healing?

So, it’s important that we bear in mind that every time we write code it’s almost like we are leaving our signature and associated personality along with the code files and it could well be analyzed and “profiled” with the next generation tools.

The How?

Again, what does it take to get this art right?  Does it depend on the problem we are trying to solve?

So, what information the Developer has? Does it depend on the time given to her to complete the task? Does it depend on the knowledge the developer has on new language features and cutting-edge technologies like the SMAC stack in today’s world?

The answer seems yes and the developer has to keep getting updated on the new language features and technology trends and coding strategies – this is a perennial process.  Though it sounds like a hard baggage to carry but for a person who LOVES learning and is inspired to create better things and has all the passion related ingredients, this seems like a natural progression.

It might be too optimistic if we conclude that somebody who knows all the new language features and modern technology trends would produce GOOD CODE. Upon getting further pensive, knowing all the new trends is analogous to a situation wherein a soldier has all the needed modern ammunition and is on the battle field. However, that may not be sufficient to win the battle for her. One needs to have a game plan, a strategy such that the right arsenal is used at the right time and, for this, one needs to think from various perspectives and one of the lessons I learnt over the years is, more calm and poised one is the better one’s strategy would be and hence having that mental PEACE while writing Code is also equally important to embrace the right coding strategy.

So seems like a developer who has a Peaceful presence of mind and Loves to learn new coding techniques and modern methodologies and understands that the code she produces reflects her personality and is like her signature, in all its probability should be able to produce Good Code.

This is just a through process from what I have observed over years as we executed multiple assignments and on that note let me conclude this Post wishing all the developers, Peace, Love and Good Code!!