3 added 307 characters in body
source | link

IMHO

if (n < 0)
  n = 0;

makes it perfectly clear that after that, n >= 0, so a comment explaining this would violate the DRY principle, and an assertion I would consider downright silly or confusing: could the author have faced some strange compiler/optimization bug at this point???  

I consider the variant using goto harder to understand than plain if. This of course may simply be the effect of not being used to seeing gotos in code; but then again, most of my (current and future) coworkers aren't either, so they probably feel the same. Thus even if I got used to goto, it would make the code harder to maintain in the long run.

It seems to me that "don't use gotos!" is one of those dogmas like "don't use multiple returns!" that stem from a time where the real problem were functions of hundreds or even thousand of lines of code.

All of the legacy programs I have seen so far contain many, many functions of hundreds (or sometimes even thousands) of lines of code. So I am very happy that at least they don't contain gotos :-) You are right that in a small, clean method goto can't make a big problem; however, if you try to draw a fuzzy line like "you can use goto in functions shorter than n lines", it is inevitably going to be abused by "clever" developers. Not to mention that functions tend to grow over time; what do you do when your originally short and clean function bloats to double its size? Do you remove the gotos then, or refactor? Will your successor a few years down the line remove the gotos, or refactor the code too?... OTOH Dijkstra's rule is clear, and has much less potential to be abused.

Last but not least, your function's name does not express its intent; renaming it to e.g. make_non_negative would leave no doubt about what it does.

YMMV.

IMHO

if (n < 0)
  n = 0;

makes it perfectly clear that after that, n >= 0, so a comment explaining this would violate the DRY principle, and an assertion I would consider downright silly or confusing: could the author have faced some compiler/optimization bug at this point???  

I consider the variant using goto harder to understand than plain if. This of course may simply be the effect of not being used to seeing gotos in code; but then again, most of my (current and future) coworkers aren't either, so they probably feel the same.

Last but not least, your function's name does not express its intent; renaming it to e.g. make_non_negative would leave no doubt about what it does.

YMMV.

IMHO

if (n < 0)
  n = 0;

makes it perfectly clear that after that, n >= 0, so a comment explaining this would violate the DRY principle, and an assertion I would consider downright silly or confusing: could the author have faced some strange compiler/optimization bug at this point???

I consider the variant using goto harder to understand than plain if. This of course may simply be the effect of not being used to seeing gotos in code; but then again, most of my (current and future) coworkers aren't either, so they probably feel the same. Thus even if I got used to goto, it would make the code harder to maintain in the long run.

It seems to me that "don't use gotos!" is one of those dogmas like "don't use multiple returns!" that stem from a time where the real problem were functions of hundreds or even thousand of lines of code.

All of the legacy programs I have seen so far contain many, many functions of hundreds (or sometimes even thousands) of lines of code. So I am very happy that at least they don't contain gotos :-) You are right that in a small, clean method goto can't make a big problem; however, if you try to draw a fuzzy line like "you can use goto in functions shorter than n lines", it is inevitably going to be abused by "clever" developers. Not to mention that functions tend to grow over time; what do you do when your originally short and clean function bloats to double its size? Do you remove the gotos then, or refactor? Will your successor a few years down the line remove the gotos, or refactor the code too?... OTOH Dijkstra's rule is clear, and has much less potential to be abused.

Last but not least, your function's name does not express its intent; renaming it to e.g. make_non_negative would leave no doubt about what it does.

YMMV.

2 added 307 characters in body
source | link

IMHO

if (n < 0)
  n = 0;

makes it perfectly clear that after that, n >= 0, so a comment explaining this would violate the DRY principle, and an assertion I would consider downright silly. or confusing: could the author have faced some compiler/optimization bug at this point???

I consider the variant using goto harder to understand than plain if. AndThis of course may simply be the effect of not being used to seeing gotos in code; but then again, most of my (current and future) coworkers aren't either, so they probably feel the same.

Last but not least, your function's name does not express its intent; if you renamedrenaming it to e.g. make_non_negative, you left would leave no doubt about what it does. 

YMMV.

IMHO

if (n < 0)
  n = 0;

makes it perfectly clear that after that, n >= 0, so a comment explaining this would violate the DRY principle, and an assertion I would consider downright silly. I consider the variant using goto harder to understand than plain if. And your function's name does not express its intent; if you renamed it e.g. make_non_negative, you left no doubt about what it does. YMMV.

IMHO

if (n < 0)
  n = 0;

makes it perfectly clear that after that, n >= 0, so a comment explaining this would violate the DRY principle, and an assertion I would consider downright silly or confusing: could the author have faced some compiler/optimization bug at this point???

I consider the variant using goto harder to understand than plain if. This of course may simply be the effect of not being used to seeing gotos in code; but then again, most of my (current and future) coworkers aren't either, so they probably feel the same.

Last but not least, your function's name does not express its intent; renaming it to e.g. make_non_negative would leave no doubt about what it does. 

YMMV.

1
source | link

IMHO

if (n < 0)
  n = 0;

makes it perfectly clear that after that, n >= 0, so a comment explaining this would violate the DRY principle, and an assertion I would consider downright silly. I consider the variant using goto harder to understand than plain if. And your function's name does not express its intent; if you renamed it e.g. make_non_negative, you left no doubt about what it does. YMMV.