If you are a C developer, look at these three explicit programming techniques

Embedded system developers should be as clear as possible , To avoid ASSUME Syndrome and unexpected behavior in its system . In today's article , Let's look at a few areas where embedded developers can clean up code in a more explicit way .

Embedded system developers should be as clear as possible , To avoid ASSUME Syndrome and unexpected behavior in its system . In today's article , Let's look at a few areas where embedded developers can clean up code in a more explicit way .

Mix of office supplies and gadgets on a wooden desk background. View from above.

Explicit programming techniques #1 – take extern Use with public functions

We all know that we should not use extern, Because it creates global variables , This may lead to various problems . however , The actual use extern A good place for is when creating public functions .

When you define an open function , You can use the following ​ ​ command ​​ Create a declaration or prototype in the header ：

Log in and copy

      
      

       
       void Foo(void);
      
      
      
      

       
       
1.
      
      

It's in the title , So it's obviously a public external function . however , I've been in this situation , You are maintaining a module written by someone else , And like Bar There is no public in the header of such a function API, But its definition is as follows ：

Log in and copy

      
      

       
       void Bar(void)
       
       
{
       
       

       
       
…
       
       

       
       
}
      
      
      
      

       
       
1.
       
       
2.
       
       
3.
       
       
4.
       
       
5.
       
       
6.
      
      

What is the purpose of this function ？ Should it be private and have an electrostatic front ？ Should it be public and defined in the title ？ If embedded developers will Bar Defined as ：

Log in and copy

      
      

       
       extern Bar(void)
       
       
{
       
       

       
       
…
       
       

       
       
}
      
      
      
      

       
       
1.
       
       
2.
       
       
3.
       
       
4.
       
       
5.
       
       
6.
      
      

We will know that it is public and in API Missing in , Although someone calls it , The linker can still find it .

Explicit programming techniques #2 – Use the pointer as const Pass to function , Unless they change

The pointer is dangerous , If they unexpectedly increase in some unexpected way during execution 、 Decrement or modification , They can easily lead to disaster . I often encounter function declarations like the following ：

Log in and copy

      
      

       
       void Foo(uint32_t * Param1);
      
      
      
      

       
       
1.
      
      

This statement is so implicit , I read this statement , The purpose is to pass a pointer to a uint32_t, Where the pointer and the point to uint32_t Memory locations can be changed ！

Is this the intention of embedded developers ？ If they just want to pass a pointer to a variable , So that it is passed by reference and can be modified by the function ？ This function can do this , But they also have the option to change the pointer ！

The following statement is very clear to me , The pointer will not change , The value of the point can be changed ：

Log in and copy

      
      

       
       void Foo(uint32_t * const Param1);
      
      
      
      

       
       
1.
      
      

The parameter is pointing to uint32_t Memory location const The pointer . The pointer cannot be changed in a function , But the point can be . therefore , If someone does the following in a function ：

Log in and copy

      
      

       
       Param++;
      
      
      
      

       
       
1.
      
      

The compiler will say “ No ！ error ！”, Let maintainers know they shouldn't do this .

Explicit programming techniques #3 – take “no reference” Variable as const Pass on

Now? , This usually excites embedded developers , And not very good . I was told it was nonsense , But the same , It makes code clear to any developer, including novices .

The idea here is that I might have a function that declares the following ：

Log in and copy

      
      

       
       void Foo(uint32_t Param1);
      
      
      
      

       
       
1.
      
      

under these circumstances , I pass parameters by copy rather than by reference , For function use . This function can theoretically perform any operation on the local copy . But the same , If someone is maintaining this code , Do they know that we want to receive parameters and use them as constants ？ For me, , Unless the statement says so , Otherwise I won't have any clue ：

Log in and copy

      
      

       
       void Foo(const uint32_t Param1);
      
      
      
      

       
       
1.
      
      

This tells me , This parameter is not expected to be changed or modified in the replica for local use .

These tips help to make the code clearer , And help embedded developers understand the true intent of the code . Now? , These may not be the best practices for implicit code that causes all these losses , But they do make you think you should write software as clear as possible .

​

This paper addresses ：​ ​https://www.linuxprobe.com/three-explicit-programming-skills-c-development.html​​