Monday, August 19, 2013

Assessing Code Quality - Part 1



Knowing what good is, and being able to articulate what code demonstrates quality is important in setting up a technology roadmap for the group.

"Easy is good, 
simple is better." 
-g.dirlam 2012

Eloquent is better than Elegant

A hallmark of  very good code is that it is "less." So this is a simple lesson, elegant code gets you good, removing code from the overall code footprint means you have achieved "very good."

In order to be useful to a business the code base does not have to house elegant solutions, if this was a prerequisite for business code then almost all  businesses would be closed. So if it does not need to be elegant than what does it need to be? Code needs to be maintainable. And it is easier to maintain smaller blocks of code than it is to  maintain large code-bases.

So it is true that good names are better than clever design patterns. It is in the nature of a programmer to be self satisfied with creating a clever solution of design patterns, but trust me, real accomplishment comes from giving all the objects in your solution names that everyone can understand.

"Give me some sugar baby," syntactic sugar allows modern programs to be more eloquent, to express relationships in compressed form. Keeping current with modern trends allow you to write inline lambda expressions that do highly complex things, in short segments of code. Use sugar, but just make sure to keep it legible.

In order to be eloquent, the programmer needs to choose fully articulate descriptive names for the objects in his code.

So some rules from Clean Code

  1. Do not add gratuitous context.
  2. Use Names based on the solution domain first, then names based on the problem domain.
  3. Use descriptive names.
  4. A method should be cohesive, and responsible for only one thing.
  5. Include only one level of abstraction in a method.

Needs to run and perform as expected

So business code needs to be maintainable, and it also must meet the needs of business, and thereby be functionally business complete. This means that that the solution meets all the actual requirements to be feature complete with the business. By this I mean that the program performs all the expected functions, that the program runs as expected and conducts business.

So to sum-up. Codes needs to perform and run properly, it needs to meet the immediate business need, it needs to be written in a clear and concise manner, it needs to be small and maintainable. If you are really industrious you can make sure it scales globally as far as localization, and that it can run a vast array of servers.



1 comment:

Unknown said...

A lot of people forget that we have a responsibility to the business to provide a solution which satisfies the business requirements in a technology and platform that is sustainable. I keep finding that developers try to push an agenda which does not necessarily do true justice to the business.