Better Multi-language Programming with Metrics
- Multi-language Coding in Modern Business
- Reworking an Example in C Using Metrics
- Reworking an Example in Java Using Metrics
- Five Steps to Better Multi-language Coding
- Summary: Metrics-Driven Coding Improves Quality
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Multi-language Coding in Modern Business
Multi-language coding is now pretty much the norm in modern enterprise development. Nearly gone are the days when a single language was used to solve all development problems. A couple of notable examples of multi-language development are GWT and PHP:
- In GWT development, you define CSS styles and HTML code, and then apply this combination to user-interface Java code. GWT testing is done in Java, and then you convert these artifacts into JavaScript. The end result is an automatically generated JavaScript module that can be deployed to a production environment. This module takes care of the knotty issues of AJAX RPC requests and provides a nice foundation for web application development. Server-side capabilities can be also be added to augment the basic coding model.
- PHP development is a lot older than GWT. Typically it involves a combination of PHP code, HTML, CSS, database access code, SQL, and so on. Often the language of choice for web application and website development, PHP is a rich and mature platform.
What does this mean for the future of software development? Getting by with expertise in just one language is becoming an increasingly difficult proposition. Software developers now commonly use a set of programming languages to deliver modern business solutions.
I recently completed a Kindle eBook on the topic of multi-language programming, Five Steps to Better Multi-language Programming Using Metrics: Simplicity in Multi-language Coding: C/C++, Java, Bash, and Python. The book is a distillation of what I think are useful multi-language software development techniques, which I’ve derived from many years of experience in a wide range of environments. Although my focus in the book is simplifying the process of handling multiple languages in a modern development project, the plain fact is that software developers can expect to encounter and solve complex questions like these:
- Is it worthwhile to expend effort on simple code, such as in the worked Bash script example?
- What guidelines can help us to survive in this multi-language world?
- What principles should we apply when reviewing multi-language code?
- How can we create tools that will analyze and report on the quality of such code?
For example, suppose you’ve been assigned the task of writing a Bash script that invokes some tricky concurrent C++ code. You might prefer to write the Bash script quickly, expending little effort toward making it a robust piece of engineering. The time you save with this approach could then be applied to concentrating on your C++ design and coding. Alternatively, you could try to design the Bash code more rigorously, only then starting on the C++ code. Which approach is “best”?
Another interesting question: Is it possible to review code in a language with which you have little or no experience? I believe the answer is yes! You can start the review process by defining and then using a set of metrics for code quality. This sounds a bit abstract, so let’s look at an example of metrics-driven development.
Use Case for Metrics-Driven Coding
Scenario: Let’s assume we’ve been asked to review some code written in a language with which we’re reasonably familiar, but not experts. However, the further assumption is that we do have some expertise in another broadly similar programming language. In the modern multi-language era, I believe it’s possible to reuse knowledge of both legacy and mainstream languages.
The burning question is this: Can we add value to the review-and-edit process with relatively limited knowledge of the target language? Using metrics, I believe it’s possible to contribute materially to the review and edit. Metrics also can help us to get up to speed with the new language.
What exactly are metrics, and how can we use metrics to address the use case I’ve just described? Metrics are simple rules that allow programmers, reviewers, and managers to look at code and broadly determine the quality of that code. In particular, metrics enable us to stand back from code and examine it with “fresh eyes.” In other words, metrics allow for a useful means of code self-review.
Reviewing code from a distance like this can help us to avoid many typical errors; it also can help to raise the quality of the code before it’s checked back into the version control system. The best kinds of metrics can be self-administered by the coder. Now let’s take a look at a comprehensive set of such metrics.
Code Quality Metrics
The following table shows problems we want to avoid in our coding efforts.
No. |
Metric |
1 |
Variable names that are too short and provide no usage context |
2 |
Code that provides no context or obvious purpose |
3 |
Inconsistent spacing |
4 |
Inconsistent parameter-type definition |
5 |
Incomprehensible code |
6 |
Code that’s too long |
7 |
No exception handling |
8 |
No automatic resource management |
9 |
External calls that are not contained in separate methods |
10 |
Inadequate abstraction (need for higher-level code) |
11 |
Code that’s difficult or impossible to change |
Did you notice that all these metrics are negative? They all describe what to avoid when coding. How often have you trudged through some virtually indecipherable code written by a predecessor? Wouldn’t it be nice if code was written to be relatively simple and understandable? This need for simplicity is a key element of metrics use.
The context of the downstream programmer is a major focus of code-quality metrics. That is, these 11 metrics represent the rules by which we can judge the quality of code examples. Metrics-driven review works best from the perspective of the downstream programmer.