Critique on design principle and validity of such in general

Question

I was hoping you could give some feedback on an idea I had for designing functions.

I am trying to think of a unifying principle for choosing what functions should return. The specific project is mostly data access classes.

So the principle is this: "When deciding what value to return as a status code, either True or False, opt to return True if the desired state is achieved."

For example, if you made a call to remove_email('email') and the email that you passed as an argument was not in the list, return True because the desired state, one in which the email is not in the database, now exists. An alternative principle might be, always return False if the exact functionality is not executed. Like removing when the email doesn't exist or the table does not exist.

I think I unifying principle like that would be helpful in creating a shared mindset in the code where we can all use it as a guiding principle.

So first, can you tell me if the principle itself is a good idea? Should a function return True if it doesn't actually do what it claims to do, like remove an item? And if this is a bad principle, is there any other principle or set of principles that are accepted as a good standard? Always throw an error code if the exact behavior does not match? Always return False? etc.

And second, is it common to have common design philosophies like this in code bases? Is so, could you provide me some examples? The closest thing that comes to mind is the Unix philosophy that a program should do one thing and one thing only. But that is more of a higher level design principle than an implementation principle.

I apologize if this is not a good question, but I am trying to learn and develop a strong fundamental understanding and I want to run these ideas by more experienced programmers to get feedback.

Answer 1

It's a matter of taste and style, however a function, in my opinion, should only return true or false if it is performing a test. It should not use a boolean value as a poor man's status code.

Now, some code bases do use status codes, in which case a byte or an int will be the go to choices. In this case you can choose to return a different state on whether the action was null or actually performed. That choice should depend on whether you need this information or not. Another option could be returning the number of rows affected -- that's what SQL returns when you call an UPDATE on a table.

Finally if your code base prefers exceptions, then don't return anything. A function updating a database is normally void and raises an exception if needed (e.g. if DB is unresponsive).

Answer 2

Yes it is common to have such design principles, but they are usually depending on the language used.

For example in C it is convention to return 0 if a function succeeds and a non-zero number, indicating an error code, if for some reason it fails.

In languages with exceptions, the convention is to throw an exception if the function cannot perform the task. Otherwise the function is assumed to have completed successfully. So no value is returned in either case.