Compiler should prevent use of a function like a subroutine

Subroutines and Functions (Commands and Queries)

 

Function: That always returns a value (return type is specified)

Subroutine: That never returns a value (void)

 

Based on the convention above the compiler gives an error if

 

1.       A subroutine returns a value

2.       The subroutine is used as a function i.e. written RHS of the variable (e.g. value = setValue())

3.        Function’s code doesn't pass all code paths with a return statement.

 

So similarly, I would like to have the compiler detect and flag an error or warning if the function is used like a subroutine. The return value should always either assigned to a variable, checked against some value in a condition (if etc.) or passed to some other function.

 

The caveat in enforcing this rule is, when applied on older programs written like this will now give errors. But newer versions of languages can have a setting in the compiler options/module level directives one like Option Explicit, Option Strict etc. in VB.NET. These way newer programs can be forced to written to include this new convention.

 

There is one more advantage of this is... Instead of throwing exceptions, programmers sometimes chose/use the return values to indicate the error conditions. This new convention forces the developer to handle the return values properly. Throwing exception is sometimes expensive. In this case user can use this new mechanism and still can have the error checks happen.

 

Compilers should be configurable with user definable rules/policies like above. For example, I would also like to get the warnings if function or sub has too many parameters. Having more than 2-3 parameters are evil to read and understand.