On Thu, May 25, 2017 at 02:59:47PM +1000, luv-main@luv.asn.au wrote:

...

and following the required coding style,

As for "required", I let the team drive the coding style requirement, as my only needs were consistency and readability. Since the team had set the style standard (mostly pilfered clauses), it was self-enforcing. Any cowboy was soon lassoed by annoyed colleagues.

by style requirements, i was mostly referring to formatting like spaces, tabs, end-of-line markers etc that you mentioned. also things like where braces belong - stupidly wasting a whole screen line on a brace or putting it on the end of the line starting the block (e.g. subroutine definition) where it belongs :) and sometimes other stuff like self-documenting code with common templates for functions etc (input, output, notes including algorithm summary, known bugs and limitations, etc)

...

built-in CI tools (e.g. you can configure it to automatically try to compile the software on every commit and report the outcome to the developer), and more.

Maybe things are different in the embedded world, but I can't remember a developer submitting code which didn't build - that would be a professional embarrassment never lived down. And the makefile could readily support a "make commit", to automate a pre-commit build. I have to admit to relying on healthy paranoia to ensure I checked that it built, before the commit.

i've seen lots of developers write and submit code that compiles perfectly on their machine in their heavily customised (idiosyncratic mess) environment that fails to build anywhere else. automated tools to build and run a test suite on every checkin is amazingly useful for catching such problems early. craig -- craig sanders <cas@taz.net.au>