The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,871 other followers

Archive for the ‘Code Quality’ Category

Software quality: economics of formality

Posted by jpluimers on 2019/11/06

Interesting read: [WayBackSoftware quality: economics of formality

At one time formal methods were thought to be the only hope for software development. That did not turn out to be the case.

Via: [WayBack] Software quality is better in practice than in theory. Formal methods improve software quality, but at a high cost that is sometimes worthwhile and some… – Jeroen Wiert Pluimers – Google+

Comment there:

Pedro Marcal:

+Jeroen Wiert Pluimers +John Cook , I think that when a code has been in service for even a short time, we can divide the code into two classes. The first is that part that has been executed at least once. The other code has never been executed. The latter code has an error rate that may be measured as a function of the language used. In the old days Fortean had a bug in every seven lines. C used to be 100 to 200 lines. We set up instrumentation to determine the number of lines tested in the first class and found that it was a linear function of the new bugs found. This was a good way to ensure a high quality code.



Posted in Agile, Code Quality, Development, Software Development | Leave a Comment »

Writing solid code the NASA way. – Lars Fosdal – Google+

Posted by jpluimers on 2019/08/29

via [WayBack] Writing solid code the NASA way. – Lars Fosdal – Google+, I bumped into  [WayBackHow To Code Like The Top Programmers At NASA — 10 Critical Rules:

Do you know how top programmers write mission-critical code at NASA? To make such code clearer, safer, and easier to understand, NASA’s Jet Propulsion Laboratory has laid 10 rules for developing software.

The rules:

  1. Restrict all code to very simple control flow constructs – do not use goto statements, setjmp or longjmp constructs, and direct or indirect recursion.
  2. All loops must have a fixed upper-bound. It must be trivially possible for a checking tool to prove statically that a preset upper-bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated.
  3. Do not use dynamic memory allocation after initialization.
  4. No function should be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function.
  5. The assertion density of the code should average to a minimum of two assertions per function. Assertions are used to check for anomalous conditions that should never happen in real-life executions. Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken, e.g., by returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule (I.e., it is not possible to satisfy the rule by adding unhelpful “assert(true)” statements).
  6. Data objects must be declared at the smallest possible level of scope.
  7. The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function.
  8. The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed. All macros must expand into complete syntactic units. The use of conditional compilation directives is often also dubious, but cannot always be avoided. This means that there should rarely be justification for more than one or two conditional compilation directives even in large software development efforts, beyond the standard boilerplate that avoids multiple inclusion of the same header file. Each such use should be flagged by a tool-based checker and justified in the code.
  9. The use of pointers should be restricted. Specifically, no more than one level of dereferencing is allowed. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted.
  10. All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these setting without any warnings. All code must be checked daily with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass the analyses with zero warnings.




Posted in Agile, Code Quality, Development, Software Development | Leave a Comment »

Clean Code is a team sport! –

Posted by jpluimers on 2019/05/28

Recommended read: [WayBackClean Code is a team sport! –

The picture is of a developer journey taking years to go from fresh to seasoned ending up at exactly the same code: over time learning the sweet spot of coding.

The story continues correlating that journey to handling technical debt and finding the sweet spot between that and business value.






Posted in Agile, Code Quality, Code Review, Development, Software Development | Leave a Comment »

Code Review Checklist – CodeProject

Posted by jpluimers on 2018/02/20

Still relevant: [WayBackCode Review Checklist – CodeProject

[WayBack]  Best “Everything Else” Article of November 2016 Ebenezar John Paul – Code Review Checklist… – CodeProject – Google+


Read the rest of this entry »

Posted in Agile, Code Quality, Code Review, Development, Software Development | Leave a Comment »

some links on git and code reviews

Posted by jpluimers on 2017/02/02

A few links I collected:


Posted in Agile, Code Quality, Code Review, Development, DVCS - Distributed Version Control, git, Software Development, Source Code Management | Leave a Comment »

%d bloggers like this: