Journal Articles

CVu Journal Vol 29, #3 - July 2017 + Journal Editorial
Browse in : All > Journals > CVu > 293 (8)
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: Editorial: It's written, that's why

Author: Bob Schmidt

Date: 08 July 2017 18:09:03 +01:00 or Sat, 08 July 2017 18:09:03 +01:00

Summary: 

Body: 

Computer programs take many forms, from the very small, probably single person hobby projects, to the mind-bogglingly large enterprise multi-tiered distributed applications. It’s rare for any program to be a write-once, deploy, forget affair, but it’s probably fair to say that the larger applications tend to have a longer lifetime, if only because they represent so much investment and effort.

We’ve not yet reached the stage where source code no longer requires human understanding, so a long-lived program needs frequent intervention by programmers: adding features, fixing bugs, maybe even improving the code. All these things require those programmers to understand not just the technology, programming languages and so on, but also the conventions used during the program’s development.

There are a whole slew of things we programmers do ‘by convention’. C++ compilers do not care how many types you define in a given file, but it’s conventional (although not universal) for it to be one. C# compilers don’t care how many lines of code per method. Javascript is famously tolerant of how much code you can fit on a single line. Conventionally, in all these cases, it is considered good practice to make the code understandable.

Some conventions can end up being more of a hindrance than a help, however. I’ve written before about the ‘I’ prefix for interface types. Others that I find unhelpful are things like namespace hierarchies encoding corporate structure – especially if the directory structure on disk has to match – and always pairing getters with setters. These conventions all, I suspect, began with good intentions, but add nothing genuinely useful, and have become so common that they take on the nature of ‘rules’ rather than ‘guidelines’.

If we take a default position of not flying in the face of convention, we run the risk of introducing unnecessary complexity almost by accident. Instead we should look critically at the things we do ‘by convention’, and only do them ‘by intention’.

Notes: 

More fields may be available via dynamicdata ..