It is subtle and requires a number of steps, some of which might conflict with the functionality of the code itself. If you are talking about a Package then some of the steps that you can take to make it difficult for a user to read and reverse-engineer the code is to:

(a) Set the Protected attribute for all functions and parameters except those that need, for functionality reasons, to remain Unprotected

(b) Set the Locked attribute for all functions and parameters except those that need, for functionality reasons, to remain not Locked. Make sure all functions and parameters in the Private sub-context of the package have the Locked attribute.

--- Note that one cannot use the SetOptions function on a function that has a Locked attribute: it will have no effect and will generate an error.

--- Any parameters or functions that are ever reset inside of the package must not be Locked. So any such functions or parameters will be reverse engineerable by the user

--- Also note that a package with Locked parameters cannot be reloaded with Get

(c) Finally you must Encode the package .m file to a file of the same name so that its ASCII representation is not human decipherable.

Adding password protection is an additional layer of complexity. I have a way to do it, but it's not foolproof (and hence something I keep confidential.) But it involves deleting the full set of functions and parameters in the package's context if the user does not provide the correct password. This has to be checked and carried out before setting any of the above Locked and Protected attributes.