Journal Articles

CVu Journal Vol 31, #5 - November 2019 + Journal Editorial
Browse in : All > Journals > CVu > 315 (7)
All > Journal Columns > Editorial (221)
Any of these categories - All of these categories

Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.

Title: Sympathy for the Devil

Author: Bob Schmidt

Date: 07 November 2019 18:27:27 +00:00 or Thu, 07 November 2019 18:27:27 +00:00

Summary: 

Body: 

The concept of ‘Code Quality’ has many facets. There is, right up front, the question of whether a piece of code is of good or bad quality. I think we all believe we recognise good or bad qualities in code. When care has been given to naming, and code is clearly laid out and simple to understand, we usually judge it as good. When code is hard to follow, too long or too wide, and names are meaningless tags for variables, we recognise it as bad quality, or at least, having less good quality.

We are usually making these judgements about code we read, which often means it was written by someone else. Are we always honest about making those same judgements of the code we’ve written ourselves? Pete Goodliffe discusses this in some detail in this edition in his latest column. One way of ensuring our own code lives up to the standards we cherish is to have it inspected by someone else. Your code may be so clear and simple that you can understand it, but if someone else believes it to be clear and simple too, then you can be really proud of it!

When we are deeply entrenched in solving some gnarly problem, it is all too easy to focus on how the code works and forget about how it looks. We can become blinkered about naming and blind to formatting. Code that provably works, runs quickly enough and passes the tests is all very well, but there are other qualities to which we need to remain vigilant. Having a fresh pair of eyes look critically over your work is a great way to avoid simple issues.

Even trivial suggestions can make large differences, such as “If this were named better, the intent would be clearer” or “Have you considered a unit test for this bit?”

The same applies, of course, when we are reviewing code for someone else. It’s easy to be critical, but harder to be constructive. If we are sympathetic to each other, then everyone can enjoy good quality code.

Notes: 

More fields may be available via dynamicdata ..