{"id":682,"date":"2014-11-19T03:51:09","date_gmt":"2014-11-19T08:51:09","guid":{"rendered":"http:\/\/www.rfdm.com\/blog\/?p=682"},"modified":"2014-11-20T00:51:53","modified_gmt":"2014-11-20T05:51:53","slug":"dont-do-this-to-your-software-team-example-3","status":"publish","type":"post","link":"https:\/\/www.rfdm.com\/blog\/?p=682","title":{"rendered":"Don’t do this to your software team, example 3"},"content":{"rendered":"

This post could easily be titled, “Don’t Party Like It’s 1998”. Even better, “Don’t Party Like It’s 2010”.<\/p>\n

I have been working on embedded software for a number of years now. First as a hobby while my “day job” was decidedly not embedded (UNIX system software, large distributed systems, etc.). Then as my day job, specifically in embedded automotive software.<\/p>\n

One of the problematic symptoms in automotive software is its use of the C language. This isn’t a C language issue: C is frequently the right tool for the job at hand in this space. The issue is that a great deal of C code I’ve seen in automotive for embedded targets is pre-1999 C. Completely absent of any of the useful features found in the 1999 C standard (ISO\/IEC 9899:1999), which is going on 16 years of age. Nevermind the 2011 C standard (ISO\/IEC 9899:2011). For what I’d call “No good reason.”<\/p>\n

Many of the automotive embedded developers I’ve worked with in the past 8 years would not fare well on a test of their knowledge of ISO\/IEC 9899:1999 (C99). This is a sad state of affairs, given that many of the features of C99 are just as useful (if not more so) in embedded development as they are anywhere else.<\/p>\n

I say there’s no good reason because the toolchains were updated more than a decade ago. The “My toolchain doesn’t support C99” excuse lost its validity more than 10 years ago. Perhaps more cocerning to me is the fact that some of the developers who aren’t knowledgeable of C99 weren’t even in the profession in 1999. In fact some of them were not far out of preschool. This saddens me because these young engineers are our future and their industry appears to be content with stunted skill set development of their software engineers. It also points to an education issue. If a developer knew nothing about C until after 1999, why is it that they were taught a version of C that predates C99 by roughly 10 years (and in many cases, predates their birth)?<\/p>\n

If you write code in C, in any industry, please don’t write your code is if it’s 1998. As I write this, it’s the end of 2014. Use C99 to your advantage!<\/p>\n

And question industry initiatives that look backward as much as they look forward. A case in point: why are so many that are involved with Autosar still oblivious to <stdint.h>\/<inttypes.h>? <stdbool.h>? Autosar was founded 4 years after C99 was ratified, and any toolchain worth using already had full C99 support. I’m using this example because at more than one place of employment, I’ve found every compiler in our toolchain to be fully C99 compliant (including optional features like extended integer types) yet found most (if not all) current projects with their own hand-coded “Platform_Types.h”, “Std_Types.h”, etc. with no sign of <stdint.h>\/<inttypes.h>. If the objective here is job security (someone has to review and potentially tweak the hand-coded header files to port code from one architecture to another), I wish them luck. If they ever want to pursue a career outside of automotive, they’ll be lacking in the knowledge needed to be successful in the language they think they’ve mastered. \ud83d\ude41<\/p>\n

Before someone sends me a defensive email: I believe Autosar is a good thing. I believe in standardized interfaces, and have leveraged them to my advantage for my entire career. And there are some Autosar vendors that are using C99 wherever they can. But when you find a wart, don’t just blindly embrace it. Find a better way. Don’t create work for yourself; seek to eliminate it. It’s the nature of any good software developer to make the next project easier. Reviewing and possibly tweaking header files every time you need to port code to a different microcontroller isn’t a good use of your time nor the company’s money. Use <inttypes.h>\/<stdint.h> in your application code. Why? Because it’ll work unchanged on every C99 compiler for every target. Including your PC for unit testing, simulation, etc. You still need Platform_Types.h for your Autosar modules, but please don’t do this kind thing that will have to be reviewed and possibly tweaked for every porting effort:<\/p>\n

\"Platform_Types_wrong\"<\/a><\/p>\n

When you can do this ONCE and be guaranteed it will work for every single target (and has for the last 15+ years), saving future work:<\/p>\n

\"Platform_Types_right\"<\/a><\/p>\n

In our own code base, which includes a fair amount of “carry-over” code from previous projects, there are some projects with literally 4 different typedefs equivalent to uint32_t. And the same for all other fixed-width integer types. More work every time someone wants to “carry over” any of that code to a new platform and finds it doesn’t work.<\/p>\n

I continue to hear developers in my industry refer to \/\/<\/code>style comments as “C++” comments, and to insist that they not be used. To be blunt: get with the game. Those aren’t “C++” comments. Those are C comments and have been for more than 15 years. And they exist for good reason; they harbor a smaller set of the dangers of \/* ... *\/<\/code> comments and involve less typing for a large class of comments (single-liners).<\/p>\n

Then there’s <stdbool.h>. Use it. A while back I ran across some old code in our project that was carried over from another project, that disturbed me (NOTE: I’m easily disturbed by such things). It looked something like this:<\/p>\n

\"BadUseOf_TRUE_FALSE\"<\/a><\/p>\n

I have to wonder how many decent C programmers literally weep when they see this kind of thing in their project, knowing that it hints at problems in the callers. Even for pre-1999 C, this breaks the spirit of boolean. If you need a uint8_t, by all means use it. But in this particular case, the right solution was simply:<\/p>\n

\"Fix<\/a><\/p>\n

If you’re a C programmer, don’t party like it’s 1998. Party like it’s at least 2000. Even better, like it’s at least 2011 (the year of _Noreturn<\/code>, etc.). Get more work done is less time, and consider improvement a life-long process. If the code you write today isn’t significantly better (tighter, easier to read, more readily tested and proven, more reusable, etc.) than the code you wrote two years ago, something is seriously wrong. Regardless of your processes, writing good software is a craft. If you aren’t seeing continuous improvement throughout your career, you’re in a rut that you need to find a way to leave.<\/p>\n","protected":false},"excerpt":{"rendered":"

This post could easily be titled, “Don’t Party Like It’s 1998”. Even better, “Don’t Party Like It’s 2010”. I have been working on embedded software for a number of years now. First as a hobby while my “day job” was decidedly not embedded (UNIX system software, large distributed systems, etc.). Then as my day job, … <\/p>\n

Continue reading “Don’t do this to your software team, example 3”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[],"class_list":["post-682","post","type-post","status-publish","format-standard","hentry","category-software-development"],"_links":{"self":[{"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/682","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=682"}],"version-history":[{"count":22,"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/682\/revisions"}],"predecessor-version":[{"id":710,"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/682\/revisions\/710"}],"wp:attachment":[{"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=682"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=682"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=682"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}