RBTLIB v0.3 Update (Part 2)

In RBTLIB v0.3 Update (Part 1) I discussed some plans for posting review requests to a Review Board instance using RBTLIB. During the development I added a complexity measure to the project.  I was intrigued by how complexity measures were used in a talk by Sandi Metz.  Sandi's talk is on Ruby.  I'm using Python.

I found two Python modules: radon and xenon that compute cyclomatic complexity. Radon computes several measures and xenon provides a way to add complexity measures to a continuous integration.

To measure the entire project, including test code from the project's root directory:

radon cc -e "ven/*" -as .

The core abstraction in RBTLIB at this point is still the Composite design pattern.
This component has the highest complexity:

rbtlib/resource/composite.py
    M 41:4 Composite.href_component - B (6)
    M 63:4 Composite.component - B (6)
    C 31:0 Composite - A (4)
    M 53:4 Composite.list_component - A (4)
    M 34:4 Composite.__init__ - A (1)

From the radon documents:

M - Module
C - Class

A - low - simple block
B - low - well structured and stable block

Overall complexity of the project thus far:

72 blocks (classes, functions, methods) analyzed.
Average complexity: A (1.88888888889)

So far, complexity doesn't appear to be a problem.

Code Matters

In Code Matters, Bertrand Meyer's discusses several flaws introduced as a result of poor language design. He cites examples from an Apple and OpenSSL security vulnerability that occurred in 2014. It's a nice discussion on the importance of language design and how it affects the implementation.

I found Meyer's discussion on root cause analysis informative, particularly the hypothetical example discussing how a combination of factors create situations that are difficult to detect. What makes Meyer's point interesting is his reference to Nancy Leveson.

Leveson's home page contains a good collection of papers on safety in engineering. One paper investigates the Therac-25, a medical device containing software issues that massively overdosed six patients. The section on "Causal Factors" is informative.

One conclusion from Leveson's paper is that focusing on particular bugs does not lead to a safe design. The mistakes attributed to the Therac-25 involve poor software engineering practices and using software to ensure safe operation. You can't patch your way out of a poor implementation and you shouldn't involve software in safety critical functions.

Meyer's point in his hypothetical example on how a combination of factors can be difficult to detect and result in catastrophic failure is made real in Leveson's discussion of "Unrealistic Risk Assessment" in the Therac-25.

It also looks like a good lesson in probabilities wherein a probability of greater than zero means that the event can occur (however unlikely).

Y􏰳G|􏰥|6j􏰡m@Z􏰇􏰮et􏰜Zom=j􏰸\][􏰣􏰽=to􏰬VZl􏰤o[􏰲􏰽􏰇t􏰼^􏰇£~􏰢􏰭􏰬XZbk ̄Z¥􏰽=j{􏰬b^bal|=j􏰡m􏰨Zl^@Z􏰇£ Zb􏰤o[􏰏􏰬􏰇j􏰓[z^=j􏰡[ym􏰇t􏰶vwu􏰥􏰢􏰏􏰬􏰇j􏰉[􏰇tl^􏰵􏰬~􏰢􏰓m􏰇tomom@Z􏰷£l^}􏰢4k1t@r􏰏m=j􏰣|4a@r~􏰢y[om=jlvwZl􏰤y[􏰾q=Z{m􏰇t􏰼uom􏰨Zl􏰤o[ymbab1⁄4"􏰳C^=t~􏰢o[6j xym@Z􏰲v􏰇t􏰼Z¥􏰽=j{􏰬􏰉m􏰇t¥􏰽􏰋Z{m6j􏰸\][􏰣􏰽􏰇ty􏰬􏰋Zl􏰤y[􏰅^􏰇t􏰓􏰬XZ􏰥􏰢􏰥|@Zom􏰉[=jl􏰤o[􏰼Zb^􏰥􏰢b􏰤{r􏰇j􏰋uRj􏰷£l^}􏰢4k~|}􏰢bab􏰴􏰅kl^=j􏰉􏰬XZ@r~􏰢o[􏰨r􏰇j􏰡m4v £b^􏰥􏰢om􏰨ZXZl^}􏰢􏰇£l^􏰨Z ̄Zom=j􏰧\][􏰣􏰽􏰇to􏰬)m􏰇t+t􏰲v􏰼kXZ􏰇􏰮􏰥|􏰇t􏰇􏰮z^􏰥􏰢VZ{m@Zb􏰤)􏰬@Zg¬=j{[y􏰬􏰥􏰢􏰼u􏰸r􏰥􏰢y􏰬􏰇j2􏰴VZl􏰤􏰧􏰦􏰫􏰳X􏰬l^􏰇t􏰥􏰢o[}􏰢4kl^􏰇t@r ̄Z􏰼u􏰇ty􏰬 m􏰨Zbkl^ba¤^􏰇t􏰥􏰢b􏰤y􏰬=j;􏰽¢kXZ{[􏰨rXZ􏰲v+􏰰􏰨Zl^ba􏰯^=j^􏰥􏰢􏰷Zg􏰮􏰻j2􏰤􏰨Z􏰶􏰴8t{[􏰚Zbk=j"u􏰚Z􏰲􏰴^=jXr`Zom=j􏰸\][􏰣􏰽=to􏰬¦􏰰Z~|bvwu􏰇t@r |􏰥|6j􏰅n}|􏰥|=j2ay[om}􏰢±;F􏰳Ru@Zo[y􏰬+ny􏰬􏰷Z¥􏰽=j{􏰬%j􏰷Zg¬=j􏰋u%t{[¤n􏰻j􏰸\Zl􏰤o[􏰠[􏰇tb^􏰠􏰬􏰥􏰢􏰱M1⁄4􏰬g£lab􏰴􏰪KêZ{m6j􏰸\][􏰣􏰽􏰇ty􏰬􏰠m=j􏰣|4a x􏰨r􏰥􏰢o[om6j2v8^􏰇t"£l^}􏰢y􏰬la􏰨r1