Coding Standards Guides Vs

(How) Can Software Quality be Improved?

Yechiel M. Kimchi The Technion, CS Faculty VLSI – Verification, Logic Synthesis, Israel Ltd.

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 1

Discovering the gap between what we know and what we do

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 2 Roadmap

• “Why Software is So Bad?” (The question, not the answer) • How to Review the Coding Process? • Expectations from Quality Software

• Some Rules for Realization of Expectations

• Coding Standards Guides vs. those Principles • Education, Management & in-betweens. • Examples and Observations • Q&A

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 3

A Word by a CS Icon

“Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated .”

Edsger W. Dijkstra, 14 June 1989

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 4 A Few References

• “Why software is so bad?” (2002) [1]

• “Why Software Fails” (2005) [2]

• “The Software Conspiracy” (1999) [3]

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 5

Some Basic Assumptions

Computer science must be at the center of software systems development. If it is not , we must rely on individual experience and rules of thumb , ending up with less capable, less reliable systems, developed and maintained at unnecessarily high cost . We need changes in education to allow for improvements of industrial practice.

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 6 Some Basic Assumptions

Quoting Bjarne Stroustrup (the father of C++) again: “… [C]orrectness, efficiency, and comprehensibility are closely related. Getting them right requires essentially the same tools .”

And I add: “… requires essentially the same mindset ” [YMK]

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 7

Why Software is So Bad?

An Interview w. Jerry Weinberg (2001) [4]

Q. “What … [are] … major milestones of SWEng. discipline in the last three decades?” A. “Well, I don’t think there have been any.” [Q. “Really?” A. “…”] Q. “What about things like reviews and testing …?” A. “… [some] just made them sloppier developers; … just more encouraged to throw stuff over the wall to testing.”

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 8 Why Software is So Bad? (cont.)

An Interview w. B. Stroustrup (2006) [5] Q. “Why is most software so bad? …” A. “… if software had been as bad as its reputation, most of us would have been dead by now.” Q. “How can we fix the mess we are in?” A. [a full page] “In theory, …: educate our software developers better, … Reward correct, solid, and safe systems. Punish sloppiness. In reality, that’s essentially impossible. I’ll review technicalities People want new fancy gadgets right now before and reward people who deliver them continue with social factors cheaply, buggy, and first. …”

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 9

Roadmap

• “Why Software is So Bad?” (The question, not the answer) • How to Review the Coding Process? • Expectations from Quality Software

• Some Rules for Realization of Expectations

• Coding Standards Guides vs. those Principles • Education, Management & in-betweens. • Examples and Observations • Q&A

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 10 How to Review the Coding Process?

I am reluctant to read M-LOC

So I have focused my attention on well known Coding Standard documents

Coding standards [from Wikipedia: Coding conventions ] Where coding conventions have been specifically designed to produce high-quality code, and have then been formally adopted, they then become coding standards. Specific styles, irrespective of whether they are commonly adopted, do not automatically produce good quality code. It is only if they are designed to produce good quality code that they actually result in good quality code being produced, i.e., they must be very logical in every aspect of their design - every aspect justified and resulting in quality code being produced.

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 11

How to Review the Coding Process?

I have reviewed

• MISRA-C (Motor Industry Software Reliability Association) • JSF AV C++ Coding Standards (F-35) – www.stroustrup.com/JSF-AV-rules.pdf • Google C++ Style Guide • Linux kernel coding style • GNU Coding Standards What should those be compared with in order to find what they miss?

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 12 How to Review the Coding Process?

What should those be compared with in order to find what they miss?

• How about comparing with the desired “ideal”? – W.r.t. my current knowledge

• Let’s go for it

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 13

Roadmap

• “Why Software is So Bad?” (The question, not the answer) • How to Review the Coding Process? • Expectations from Quality Software

• Some Rules for Realization of Expectations

• Coding Standards Guides vs. those Principles • Education, Management & in-betweens. • Examples and Observations • Q&A

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 14 Expectations from Quality Software

The Structure of Software Software

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 15

Expectations from Quality Software

Software is Fractal like What are the recurring Parts ? An atomic (leaf) part , is a Section of code Software Library Component Module ADT Class Function/Procedure Command (loop/conditional) Expression (operator/function call) Some of the inclusions may be reversed Where does a package fit in?

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 16 Expectations from Quality Software

What is Common to these Parts ?

Service = Interface + Implementation

Interface = Preconditions + Post Conditions . - Invariants

Implementation = As Independent As Can Be (*)

Using Inclusion- (*) Independent Commands/Expressions ? Exclusion An Opportunity for Concurrency

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 17

Expectations from Quality Software

Meta-Rule: Software is a collection of parts that are governed by same requirements • Independence • Separation • Controlled communication (Interface) • Simplicity How can these requirements I ignore uniformity rules, be translated into which are really stylistic language-independent rules?

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 18 Roadmap

• “Why Software is So Bad?” (The question, not the answer) • How to Review the Coding Process? • Expectations from Quality Software

• Some Rules for Realization of Expectations

• Coding Standards Guides vs. those Principles • Education, Management & in-betweens. • Examples and Observations • Q&A

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 19

Practical Rules

Independence No goto Did you know? There are three versions of goto • Control: The well known goto command - Allows two sections to mix their commands Which one • Value: Global variables - Allows several sections to shareis values worst? - Using a value created by an unknown section • Type: Using ptr/ref casting (*) - It’s not a conversion, it is an assumption

(*)(*) Thanks to Marshall Cline, owner of C++ FAQs Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 20 Practical Rules

What’s Worse? a cross-module goto or a global variable

ModuleB ModuleB

ModuleA ModuleA

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 21

Practical Rules

Separation Two common techniques for separation are hiding & hiding implementation

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 22 Practical Rules

Separation Modularity

VS.

Example : If a function contains two loops, it is almost impossible . to test one of them separated from the other

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 23

Practical Rules

Separation Functions

The Biggest Misconception

About Functions (000)

(000) Except interface functions

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 24 Practical Rules

Separation Functions

The Purpose of Functions is

to Eliminate Code Duplication

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 25

Practical Rules

Separation Functions The Purpose of Functions is to make the Code Easier to Understand

• By naming a piece of code (saving comments) • By hiding its implementation (high level code) • By making pre/post-conditions explicit – Also allowing (partial) isolation for testing • By making the hosting code/function shorter

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 26 Practical Rules

Separation

• Functions are for easy understanding • Separation of concerns (aka the SRP) • The evil of code-duplication (*) • Encapsulation

• No getters. (*) The lesson of Ariane5: Not same environment

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 27

Practical Rules

Controlled communication (Interface)

• Minimize number of users (|Width| = |I|*|U| = i Ui)

• Minimal and complete (S. Meyers Eff. C++ 2 nd ) • Make pre/post-conditions explicit – Minimize side-effects • Interface should preserve invariants – No setters

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 28 Practical Rules

Simplicity

• Short functions (and a single task)

• Shallow nesting - low (cyclomatic) complexity

• Minimize function’s side-effect

• Function side-effects via interface (visible)

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 29

Roadmap

• “Why Software is So Bad?” (The question, not the answer) • How to Review the Coding Process? • Expectations from Quality Software

• Some Rules for Realization of Expectations

• Coding Standards Guides vs. those Principles • Education, Management & in-betweens. • Examples and Observations • Q&A

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 30 Coding Standards Guides

I argue that coding standards documents: • Miss most of the aforementioned coding rules • Have stuff that should be put elsewhere.

Indeed, the guides are more about low level style – e.g., uniformity and language don’t s + mini-rules.

Those are very important in practice, but they do not replace the general rules.

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 31

Related to the Rules Above

MISRA-C (2004) has: • “Minimal” scope for variables [in a function]

• “ Whether objects are declared at the outermost or innermost block is largely a matter of style” [Oops?] • Restrictions on pointer casting (advice) • No goto/continue (break is restricted) • Functions have a single point of exit at its end

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 32 OOPS

In “C Unlished” (SAMS, 2000), p. 206, we see

Warning: ‘len’ is int main(void) assigned a value { that is not used size_t len = 0; char buffer[1024] = {0}; if (fgets(…) != NULL) After a long discussion, on p. 208 it’s written: { len = strlen(buffer); “If you ever find a style that will, printf(…); for any program, produce no } warnings at all under all ANSI C compilers at their pickiest warning return 0; In this case: Declare len level, the world would be very } inside if block glad to hear from you.”

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 33

Related to the Rules Above

JSF-AV C++ (2005, based on MISRA-C ) has: • Class interface should be complete and minimal • Const member functions are better • Usage of invariants (advice) • No goto/continue (break is restricted) • Avoiding global variables (advice) • Restricts down-casting (and casting in general)

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 34 Coding Standards Guides

A Possible Reservation: The missing rules are expected to be well known by their knowledgeable engineers.

Indeed, it is possible. But then, how come they have the following rules?

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 35

Mistrust at Coding Standards Guides

MISRA-C (2004) has: • 12.3 (req) The sizeof operator shall not be used on expressions that contain side effects. - [They are worried programmers will expect evaluation] • 16.8 (req) All exit paths from a function with non-void return type shall have an explicit return statement with an expression. • 17.6 (req) The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist. - [See below] (*)

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 36 Mistrust at Coding Standards Guides

JSF-AV C++ (2005) has: • #60 (as MISRA-C) The sizeof operator … • #81 The assignment operator shall handle self-assignment correctly • #82 An assignment operator shall return a reference to *this • #111 A function shall not return a pointer or reference to a non-static local object - [See below] (*)

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 37

Coding Standards Guides

(*) The first day I’ve got the new, 3 rd edition, of Stan Lippman’s C++ Primer , I found three related errors: an automatic variable returned by reference. Stan’s response to my e-mail was not just apologetic – he couldn’t understand how that error eluded both his review as well as the technical reviewers.

Do you think that a rule such as the above white board white could have helped them?

– Such rules belong to learning – Most are checked by lint-like tools

Coding standard is about conscious activity not about unintentional errors

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 38 Organizing Coding Standards Guides

Principles Uniformity Issues - Best known practices - Naming - Mostly language independent - Structure of code - Many not statically diagnosed - Organization of code Separated? Project’s Requirements Automatic? - Hopefully statically diagnosed Personal via IDE? - E.g., GUI is not Embedded Exceptions

Language Knowledge Exist does not belong here Everywhere

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 39

Misguided Coding Standards Guides

More from JSF-AV C++ (2005) has (# is rule’s no.) : • #1 Any one function (or method) will contain no more than 200 logical source lines of code (L-SLOCs). - Rationale: Long functions tend to be complex and therefore difficult to comprehend and test. • #3 All functions shall have a cyclomatic complexity number of 20 or less - Rationale: Limit function complexity.

I cannot politely comment on #1, but here is an explanation for #3

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 40 Coding Standards Guides

Cyclomatic Complexity: McCabe, 1976 The diagrams are from the original paper defining cyclomatic complexity.

The one on the left is measured 8 (no backward arcs).

The one on the right is measured 19 : It has 11 backward arcs (all the curved ones on the right), some only partially overlapped – meaning they must be goto s, not loops. Go back to rule #3.

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 41

Roadmap

• “Why Software is So Bad?” (The question, not the answer) • How to Review the Coding Process? • Expectations from Quality Software

• Some Rules for Realization of Expectations

• Coding Style Guides vs. those Principles • Education, Management & in-betweens. • Examples and Observations • Q&A

Haifa Tech-Talk, April 2016 © by Yechiel M. Kimchi 42 From Education to Management

There are computer-scientists that claim that Programming is a Tool My reaction is: • You are right , but the difference between us is

• You think of it as the plumber ’s hammer and chisel – Break the wall, fix the leak and cover. • I think of it as the sculpturer ’s hammer and chisel – If you don’t use it the right way, you’ll break the marble.

From Education to Management

Unless one objects to most what I have presented, the conclusions are mostly obvious . Here is my take: • First programming course – by SW-Eng literate staff. – Bad habits are hard to change (contrary to good habits) – Otherwise, programming is a tool – not a profession . • Other programming courses – by SW-Eng. aware staff. – E.g., if HW is programming, TAs should be knowledgeable. • Gradually introduce the rules (only half were presented) – Explain the rules’ rational (they are essence , not style)

Cooperate with the industry – when you’re welcome (I know of a case were even success didn’t change attitude) Here is my take: • Industry is good at fighting bugs – not at eliminating them – There are many great bug tracking systems – There is no single non-bug tracking system

• Industry spends M-$ on testing Are testers paid – But much less on educating their engineers less than SWE? – “Your code must be maintainable by the least experienced team member” • Industry spends M-$ on process – But how much on contents? There is recall on HW (cars, Intel® Pentium®), not on SW

Approaches to Software Quality

(*) See Stroustrup, acm2010, slide#6 • Most approaches are process based ( !CS (*) ) – CMMI (Capability Maturity Model Integration): www.sei.cmu.edu/cmmi(1 st sentence) – XP (eXtreme Programming): extremeprogramming.org (2 nd sentence) – PSP (Personal Software Process [Humphrey 95] ) CMU/SEI-2000-TR-022 W.S.Humphrey “To produce quality products, engineers must feel personally responsible for the quality of their products. Superior products are not produced by mistake; engineers must strive to do quality work .” Principle #3 (out of 6) CMU/SEI-2000-TR-022 p.5

An Important Observation • Processes mainly aim at collaboration level, from a team – up to a corporation. • The basics of software development is done at the personal level, individually. • Therefore, a software development group, no matter its size, resembles a team of chess players – not a football team.

It Usually Works, because …, but …

• Because developers do argue that each piece of code they write fulfills its task • But , [PSP]: “even experienced programmers inject a defect in every seven to ten lines of code” [Hayes and Over: CMU/SEI-97-TR-001] , • Maybe, in too many cases, arguing is done too superficially. • Arguing about code correctness is difficult .

A parent of C and UNIX

Wired headline was (http://www.wired.com/wiredenterprise/2011/10/thedennisritchieeffect/ ) Dennis Ritchie: The Shoulders Steve Jobs Stood On

Last paragraph in the NYTimes obituary (http://www.nytimes.com/2011/10/14/technology/dennis-ritchie-programming- trailblazer-dies-at-70.html ) Colleagues who worked with Mr. Ritchie were struck by his code — meticulous, clean and concise . His writing, according to Mr. Kernighan, was similar. “There was a remarkable precision to his writing,” Mr. Kernighan said, “no extra words, elegant and spare, much like his code.”

Resisting Changes

ACCU Meeting, speaker: Dan Saks 10/25/11 (abstract)

Most programmers fancy themselves to be rational and objective, more so than the general population. Recent research suggests this self image might have a basis in fact. Nonetheless, C and C++ programmers still cling to programming styles and practices which are unsupported by evidence and sometimes even contradicted by it.

Comedian Stephen Colbert has popularized the word "truthiness" to describe the human trait of knowing something "from the gut" without regard to actual facts. This talk takes a lighthearted look at C and C++ programmers' truthiness in the hope of inspiring more truthfulness.

Num. of Matching Principles (out of 25) Misra-C: Only 1 Linux-Kernel: 6 Alexandrescu-Sutter: 11 +KISS Joint Strike Fighter (F-35): +9 -3 Google (Style Guide): 8 + 1 - 2

Roadmap

• “Why Software is So Bad?” (The question, not the answer) • How to Review the Coding Process? • Expectations from Quality Software

• Some Rules for Realization of Expectations

• Coding Style Guides vs. those Principles • Education, Management & in-betweens. • Examples and Observations • Q&A

A Simple C++ Industrial Example PlumberStatus (identifiers were renamed) Tap::open_tap(const string& tap_name) { LockSys LL(tap_lock_); TapMap::const_iterator it = taps_.find(tap_name); if (it == taps_.end()) { return PLUMB_TAP_NOT_FOUND; } it->second->operate(true); return PLUMB_OK; }

Examples and Observations

What’s the difference? PlumberStatus Tap:: close _tap(const string& tap_name) { LockSys LL(tap_lock_); TapMap::const_iterator it = taps_.find(tap_name); if (it == taps_.end()) { return PLUMB_TAP_NOT_FOUND; } it->second->operate( false ); return PLUMB_OK; }

What’s The Problem? • Is it code duplication ? – Let’s see: • After extracting out the maximal possible common part PlumberStatus Tap::open_tap(const string& tap_name) { LockSys LL(tap_lock_); if (!tap_found(tap_name)) { return PLUMB_TAP_NOT_FOUND; } Oops… it ->second->operate(true); return PLUMB_OK; }

Code Duplication is just the Symptom

The real problem: Each one of them has two tasks

• Delegation (of a function call)

• Wrapping: Transforming boolean value => name

PlumberStatus Tap::operate_tap(const string& name, bool open) { LockSys LL(tap_lock_); TapMap::const_iterator it = taps_.find(tap_name); if (it == taps_.end()) { return PLUMB_TAP_NOT_FOUND; } it->second->operate(open); return PLUMB_OK; }

Single Task Implementation – Wrappers

inline PlumberStatus Tap::open_tap(const string& tap_name) { return operate_tap(tap_name, true);} Both functions are inline d, so there is no space/time overhead inline PlumberStatus Tap::close_tap(const string& tap_name) { return operate_tap(tap_name, false);}

With appropriate design, these may be made non-member non-friend functions

It enforces awkward usage

if (activation_required) { open_tap(name); } else { close_tap(name); }

Instead of

operate_tap(name, activation_required);

Resisting Changes (industrial example)

if (A) { Some developers claim the alternative value = true; will not be understood by new hires. } else if (B) { value = false; } else if (C) { value = false; } else { value = true; }

////// An Alternative ////////

value = A || (!B && !C);

The above is idiomatic in C and C++. Therefore, we can choose between 1. Gradually elevating our new hires’ knowledge to a professional level. 2. Adjusting our professional code to meet our new hires’ knowledge.

if (A) { Some claim the alternative will value = true; not be understood by NCGs } else if (B) { (new college graduates). val ve = false; } else if (C) { value = false; } else { value = true; }

////// An Alternative ////////

value = A || (!B && !C);

The latter version is the way to guarantee assignment is to a single variable

Q & A

[1] Charles C. Mann “Why software is so bad?” MIT Technology Review, 2002 http://www.technologyreview.com/featuredstory /401594/why-software-is-so-bad/ [2] Robert N. Charette “Why Software Fails” IEEE Spectrum 2005 http://spectrum.ieee.org/computing/software /why-software-fails/ [3] Mark Minasi, “The Software Conspiracy”, Mcgraw-Hill, 1999

Sources (cont.)

[4] Beth Layman “An Interview w. Jerry Weinberg” Software Quality Professional, v.3 no.4, 2001 ASQ http://www.stickyminds.com/interview/software- engineering-state-practice-interview-jerry-weinberg [5] J. Pontin, “The problem with Programming: Interview w. B. Stroustrup”, MIT Technology Review, 2006 http://www.technologyreview.com/news /406923/the-problem-with-programming [6] Y. Kimchi, “Coding with Reason”, in “97 Things Every Programmer Should Know”, ed. K.Henney, O’Reily 2010