UsbX example

[Eiffel]

Hi ST,

i have one question for you. Could you please make "examples" more messy? Is it even possible? Lets see, i believe you can do it even worse. 

To be honest, i have never saw this nonsense and mess in my life. And i have also worked as ABAP developper. 

Have you ever heard about rule, that strongly recommends NOT to use "goto"? No? I thought so.

Have you ever heard about spaghetti code? Because you created one really huge. 

That example about UsbX for Stm32u5 is awfull. Who did it? Intern? Student? 

What is wrong with you? Even renesas is now better than you. 

[Pavel A.]

@Eiffel 

> Have you ever heard about rule, that strongly recommends NOT to use "goto"?

AFAIK there's no such rule. Some projects and teams have their coding& style standards, others have other standards. In plain C, goto often helps reducing cyclomatic complexity.

[Eiffel]

Every single project and team have coding style standards. 

In plain C, goto cause mess. What about to use longjump? Where it will end? Why not to write code directly in main function.

The use of goto is just poor experience. Same as while loops in HAL codes. 

[Pavel A.]

Obviously you are not familiar with Linux kernel codebase.

Well, people get used to any circumstances, even to MISRA  :persevering_face: or AUTOSAR conventions - and like them.

[Eiffel]

No, i am not. And hope never will have to.

Why is misra or autosar bad? I like it. It make code more readable and stable. Also it speed up development process when you dive into it.

[CTapp.1]

Though MISRA only advises that goto should not be used ;)

However, it does not allow back jumps to be used to create loops, jumping over initializers, jumping between switch cases...

[Eiffel]

You shall also not shoot yourself in leg. But some people do that. Is that ok? 

If there is an advise, there is usually good reason for it.

[CTapp.1]

MISRA revised its guidance on the use of goto from "shall not be used" (required) in 2004 to "should not be used" (advisory) in 2012, in acknowledgement that, in a limited number of cases, the use of goto is the "correct" solution. At the same time, it introduced (required) guidance to limit how goto is used to prevent undesirable use.

Changing the initial (2004) rule from "required" to "advisory" makes it much easier for a project to use goto when complying with the "required" rule that was introduced in 2012. It is also perfectly acceptable for a project to re-categorize the (now "advisory") rule as "required" or "mandatory", as is permitted under MISRA Compliance - meaning that the use of goto is either prohibited (when "mandatory"), or needs to be supported by a deviation (when "required"). MISRA re-worked the rules in this way to acknowledge that appropriate use should be easy whilst still allowing a project to prohibit its use entirely.

Note that there are a number of other areas within MISRA where an "advisory" rule is used to recommend that a feature should not be used, with one or more "required" rules being used to restrict its use where that recommendation is not followed. This allows a project to determine which parts of the language are or are not permitted, allowing the guidelines to be more easily adopted by projects having different safety requirements.

[Pavel A.]

You have lifted the heavy stone from my heart, Mr. Tapp.