jm + code-reviews   4

GitHub now supports "squash on merge"
yay.

On the other hand -- http://www.thecaucus.net/#/content/caucus/tech_blog/516 is a good explanation of why not to adopt it. Pity GitHub haven't made it a per-review option...
github  code-reviews  squashing  merges  git  coding 
april 2016 by jm
Coders performing code reviews of scientific projects: pilot study
'PLOS and Mozilla conducted a month-long pilot study in which professional developers
performed code reviews on software associated with papers published in PLOS
Computational Biology. While the developers felt the reviews were limited by (a) lack of
familiarity with the domain and (b) lack of two-way contact with authors, the scientists
appreciated the reviews, and both sides were enthusiastic about repeating the experiment. '

Actually sounds like it was more successful than this summary implies.
plos  mozilla  code-reviews  coding  science  computational-biology  biology  studies 
january 2014 by jm
Toyota's killer firmware: Bad design and its consequences
This is exactly what you do NOT want to read about embedded systems controlling acceleration in your car:

The Camry electronic throttle control system code was found to have 11,000 global variables. Barr described the code as “spaghetti.” Using the Cyclomatic Complexity metric, 67 functions were rated untestable (meaning they scored more than 50). The throttle angle function scored more than 100 (unmaintainable).
Toyota loosely followed the widely adopted MISRA-C coding rules but Barr’s group found 80,000 rule violations. Toyota's own internal standards make use of only 11 MISRA-C rules, and five of those were violated in the actual code. MISRA-C:1998, in effect when the code was originally written, has 93 required and 34 advisory rules. Toyota nailed six of them. Barr also discovered inadequate and untracked peer code reviews and the absence of any bug-tracking system at Toyota.


On top of this, there was no error-correcting RAM in use; stack-killing recursive code; a quoted 94% stack usage; risks of unintentional RTOS task shutdown; buffer overflows; unsafe casting; race conditions; unchecked error code return values; and a trivial watchdog timer check. Crappy, unsafe coding.
firmware  horror  embedded-systems  toyota  camry  safety  acceleration  misra-c  coding  code-verification  spaghetti-code  cyclomatic-complexity  realtime  rtos  c  code-reviews  bug-tracking  quality 
october 2013 by jm
Rusty's API Design Manifesto
This classic came up in discussions yesterday...

In the Linux Kernel community Rusty Russell came up with a API rating scheme to help us determine if our API is sensible, or not.  It's a rating from -10 to 10, where 10 is perfect is -10 is hell. Unfortunately there are too many examples at the wrong end of the scale.
rusty-russell  quality  coding  kernel  linux  apis  design  code-reviews  code 
may 2013 by jm

Copy this bookmark:



description:


tags: