Hacker News new | past | comments | ask | show | jobs | submit login

I actually prefer your second form: return as soon as you know you are done in the function/method -- if nothing more can be done, then don't pretend to do any more.

In the case of cleanup that must be done in the end, perhaps 2 functions would be better: a top level func to acquire and dispose of resources, calling an inner func to do as much work as it can with the resources. (assuming something like C that doesn't have a "finally" clause like Java)

I've never understood how finding the end of a long / nested mess of if/else blocks, rather than leaving the function, is somehow better. Which one feels more like a GOTO in terms of least astonishment?




   > I actually prefer your second form: return as soon as
   > you know you are done in the function/method -- if 
   > nothing more can be done, then don't pretend to do 
   > any more.
The first form actually does that. As soon as one if condition fails, the code falls through down to the bottom and returns. This is most impressive in the initialization/identification phase (see sdio_open() [1]) because that has like a dozen commands it has to get through successfully. By collapsing this way it allows for common cleanup, and if the cleanup requirements change you only have to change it in one place.

The effect of the first form (in C) is to collapse all of the if's "else" clauses into a single one at the bottom.

As for finding the other end of an off screen if clause, I agree with you, that it is a crutch to use the 'find matching' command in the editor with the open brace. The interesting about this problem is that it is driven by the SDIO spec, which was driven by a strict requirement of backwards compatibility, which results in very carefully crafted command / response / flow options.

This discussion has been helpful for me as at some point I am going to have to describe this to people new to, or possibly unfamiliar with, programming which should be interesting.

[1] https://github.com/ChuckM/stm32f4-sdio-driver/blob/master/sd...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: