On Thu, May 25, 2017 at 02:59:47PM +1000, luv-main(a)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(a)taz.net.au>