Using a Time-Of-Flight LIDAR Sensor

Re:Using a Time-Of-Flight LIDAR Sensor by teraflop on Thursday December 08, 2016 @11:51AM (#13131681)

That change would decrease the repeated code, but I think it would also make the code more brittle. What if the requirements were very slightly different, and you needed to do something different in the middle of the sequence, like writing a register of a different size or sleeping for a millisecond?

This situation is crying out for either exception handling, or Go's "errors are values" pattern. (https://blog.golang.org/errors-are-values)

[ Parent | on HN ]

Re:Using a Time-Of-Flight LIDAR Sensor by MaulingMonkey on Thursday December 08, 2016 @12:31PM (#13132125)

> What if the requirements were very slightly different, and you needed to do something different in the middle of the sequence, like writing a register of a different size or sleeping for a millisecond?

Interestingly, I'd argue this is actually a great argument for brittleness in this case. The table oriented code makes it clear to the reader that no such subtle edge cases exist, improving the readability of the code.

Although a local macro or better error handling system would also make such things a bit clearer too.

[ Parent | on HN ]

Re:Using a Time-Of-Flight LIDAR Sensor by LeifCarrotson on Friday December 09, 2016 @01:11AM (#13137024)

> The table oriented code makes it clear to the reader that no such subtle edge cases exist,

As an occasional embedded systems programmer, initialization code without subtle edge cases only exists in artificial examples like this one.

[ Parent | on HN ]