3 ms·

Believe me, I know what it is. This just isn't the way to do it. Hiding a goto in a macro is bad. Hiding a goto in a nested macro is even worse. Sure, it's fine

Believe me, I know what it is. This just isn't the way to do it. Hiding a goto in a macro is bad. Hiding a goto in a nested macro is even worse. Sure, it's fine right now, but this is setting the project up for maintenance nightmares. What's the benefit of this way over a more explicit coding style? The only benefit is saving a few lines of typing. Code is typed once and read 1000's of times. It's better to optimize code for reading, not for writing. Feel free to read the Joint Strike Fighter (JSF) coding standards which says "Goto shall not be used", and "Macros shall not be used, inline functions are preferred". Also, see NASA's Joint Propulsion Labs (JPL) coding standards where they recommend against using goto, and only allow simple macros (hint: a goto inside a macro is not simple). Some really smart people put a lot of effort into creating coding standards for critical systems. Even if you don't believe me, when Bjarne Stroustrup is hosting the coding standard on his personal website you might want to pay attention. http://www.stroustrup.com/JSF-AV-rules.pdf http://www.stroustrup.com/JSF-AV-rules.pdf http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

retrogradeorbit 11y ago
Just as a side note, have you looked at the systemd source code? It has many, many with gotos (and sprintfs and hard coded buffer sizes and... and...)
- intelfx 11y ago
  Just as a side note to side note (preemptive strike against accusations of systemd for using gotos) — the Linux kernel has many of them either. This is idiomatic C-style error handling. Also note that systemd employs gcc's __attribute__((cleanup(...))) logic to improve code clarity.
- asynchronous13 11y ago
  No, I haven't looked at systemd source code. Does it have gotos hidden in macros, too? There are many practices that used to be common that we have learned should not be common. Hopefully a new project doesn't repeat the mistakes of the past. From earlier this year, NASA's 10 rules for safety critical systems [1]: Rule 1: Restrict all code to very simple control flow constructs. Do not use GOTO statements, setjmp or longjmp constructs, or direct or indirect recursion. I don't think gotos are inherently bad, but I choose to heed the advice of people with more experience than me. (I do think that hiding gotos in macros is inherently bad, though.) [1] http://sdtimes.com/nasas-10-rules-developing-safety-critical-code/ http://sdtimes.com/nasas-10-rules-developing-safety-critical...
tmd83 11y ago
I also used to exhaustively follow the no goto rule. Not that these days I have much reason to mostly coding in java. Goto is definitely very easy to use but there are a lot of scenarios where the code that you write trying not to use goto can be much more butprone and complicated to understand. Not everyone is sort of semi-infinite budget for their project though I agree we probably need to do a better job in maturing in discipline. On the other hand no other engineering will be asked to change the requirement and spec hundreds of time during its lifetime either since that would be impossible to achieve.

retrogradeorbit 11y ago

Just as a side note, have you looked at the systemd source code? It has many, many with gotos (and sprintfs and hard coded buffer sizes and... and...)

intelfx 11y ago
Just as a side note to side note (preemptive strike against accusations of systemd for using gotos) — the Linux kernel has many of them either. This is idiomatic C-style error handling. Also note that systemd employs gcc's __attribute__((cleanup(...))) logic to improve code clarity.
asynchronous13 11y ago
No, I haven't looked at systemd source code. Does it have gotos hidden in macros, too? There are many practices that used to be common that we have learned should not be common. Hopefully a new project doesn't repeat the mistakes of the past. From earlier this year, NASA's 10 rules for safety critical systems [1]: Rule 1: Restrict all code to very simple control flow constructs. Do not use GOTO statements, setjmp or longjmp constructs, or direct or indirect recursion. I don't think gotos are inherently bad, but I choose to heed the advice of people with more experience than me. (I do think that hiding gotos in macros is inherently bad, though.) [1] http://sdtimes.com/nasas-10-rules-developing-safety-critical-code/ http://sdtimes.com/nasas-10-rules-developing-safety-critical...

tmd83 11y ago

I also used to exhaustively follow the no goto rule. Not that these days I have much reason to mostly coding in java. Goto is definitely very easy to use but there are a lot of scenarios where the code that you write trying not to use goto can be much more butprone and complicated to understand. Not everyone is sort of semi-infinite budget for their project though I agree we probably need to do a better job in maturing in discipline. On the other hand no other engineering will be asked to change the requirement and spec hundreds of time during its lifetime either since that would be impossible to achieve.