[siddharthgoel88]

I noticed that people have already contributed great insights on readability and testability aspects which were my first thoughts as well on reading this blog.

However, I do believe that there is no one right answer to this argument. And the right answer is with that team who in the end have to read, write and maintain that code. The metrics that I collect with my co-workers who work on same code base as me are

  * What is the cognitive load to grasp the code for members in the team?  
  * How easy is it to onboard a new member to this team?
  * Are we able to move fast and have confidence in the code changes we make?

In my opinion, metrics like these are usually the ones most of us care about in the end.

[weatherlight]

so that team knows all future hire? I work on code bases that were written 15 years ago by a plethora of people in different imperative styles. where business requirements changed a lot over that 15 year period.

There's a lot of spaghetti code.

we found There's a strong correlation between method/function size and bugs.

There's not a lot of confidence because there's implicit mutable state and side effects all over the place.