8 ms·

https://github.com/nmrugg/stockfish.js/search?q=goto https://github.com/nmrugg/stockfish.js/search?q=goto Five occurrences of goto, for anyone that's curious.

by Cpoll 5y ago

https://github.com/nmrugg/stockfish.js/search?q=goto https://github.com/nmrugg/stockfish.js/search?q=goto Five occurrences of goto, for anyone that's curious. The code is pretty easy to read, good variable names, some explanatory comments. The gotos don't make spaghetti. I'm inclined to think the writers knew what they were doing, though goto offends my sensibilities as much as anyone. Could anyone with more experience explain the pattern? Why gotos for control flow along with >thousand line functions?

mhink 5y ago
Interesting. I was looking at the algorithm in evaluate.cpp [0] and it seems to be the case that the control flow is pretty much just an alternative to if-statements... which, personally, I find to be more readable than it'd otherwise be if it were heavily nested. I'm open to arguments otherwise, though. Consider two alternatives (written in pseudo-Javascript, I guess): let xyz = 0; if (!condition1) { doSomething(); xyz = getValueSomehow(); if (!condition2) { doSomethingElse(); xyz += getSomeOtherValueSomehow(); } } finishUpBusinessLogic(); return xyz; that seems much less readable than: let xyz = 0; if (condition1) goto done; doSomething(); xyz = getValueSomehow(); if (condition2) goto done; doSomethingElse(); xyz += getSomeOtherValueSomehow(); done: finishUpBusinessLogic(); return xyz; 0: https://github.com/nmrugg/stockfish.js/blob/d96c98872103c60b713e986901dd1e22986e9280/src/evaluate.cpp https://github.com/nmrugg/stockfish.js/blob/d96c98872103c60b...
- kilburn 5y ago
  The hidden side-effects of your example code make it hard to reformat, but in general people don't advocate for your first example. The push is more towards defining smaller logic blocks (with names that hint at what they do): def computeSomething() { if (condition1) return 0; let value = getValueSomehow(); if (condition2) return value; doSomethingElse(); return value + getSomeOtherValue(); } let value = computeSomething(); finishUpBusinessLogic(); return value;

by Cpoll 5y ago

mhink 5y ago

Interesting. I was looking at the algorithm in evaluate.cpp [0] and it seems to be the case that the control flow is pretty much just an alternative to if-statements... which, personally, I find to be more readable than it'd otherwise be if it were heavily nested. I'm open to arguments otherwise, though. Consider two alternatives (written in pseudo-Javascript, I guess): let xyz = 0; if (!condition1) { doSomething(); xyz = getValueSomehow(); if (!condition2) { doSomethingElse(); xyz += getSomeOtherValueSomehow(); } } finishUpBusinessLogic(); return xyz; that seems much less readable than: let xyz = 0; if (condition1) goto done; doSomething(); xyz = getValueSomehow(); if (condition2) goto done; doSomethingElse(); xyz += getSomeOtherValueSomehow(); done: finishUpBusinessLogic(); return xyz; 0: https://github.com/nmrugg/stockfish.js/blob/d96c98872103c60b713e986901dd1e22986e9280/src/evaluate.cpp https://github.com/nmrugg/stockfish.js/blob/d96c98872103c60b...

kilburn 5y ago
The hidden side-effects of your example code make it hard to reformat, but in general people don't advocate for your first example. The push is more towards defining smaller logic blocks (with names that hint at what they do): def computeSomething() { if (condition1) return 0; let value = getValueSomehow(); if (condition2) return value; doSomethingElse(); return value + getSomeOtherValue(); } let value = computeSomething(); finishUpBusinessLogic(); return value;