14

I heard somebody say their language has a convention where the names of functions which mutate state must end with an exclamation point. I'm trying to write more functional code and I like the idea of somehow marking functions according to their side effect status i.e. none, inward side effects, outward side effects (I'm ignorant of the right fp terminology but you get the idea I hope).

Obviously it's easy for me to come up with my own naming scheme but I was wondering if such schemes/conventions already exist before I go and homebake one.

edit: Thanks for all the responses, that was exactly what I was after and I found them all genuinely useful. I probably should have mentioned I am refactoring some old javascript so, while statically typed languages may be able to enforce a difference between code with and without side effects I will have to rely on a self imposed naming convention.

edit2: As for the mods closing this as primarily opinion based I have to disagree. I was asking what, if any, conventions were in common use - this is by anyone's definition a question of fact not opinion!

Roger Heathcote
  • 383
  • 2
  • 7
  • 1
    This is likely to vary between languages and is likely to be very opinion-orientated. – David Arno Oct 04 '16 at 16:02
  • 2
    For example, Scala's convention is to declare methods without parentheses (much like properties), unless they have side effects. But you can't use this in any other language that I know of. The exclamation point seems horrid to me; there are too many other uses for that symbol, and I would find it being used to mark methods distracting. – Robert Harvey Oct 04 '16 at 16:08
  • 2
    @RobertHarvey I believe Scheme is a language that uses that convention, and the convention exists because the operator to mutate the state of a variable is `!` (it wouldn't be syntactically valid to mutate the state of a variable without that operator, if memory serves), so it actually is a rather sensible convention *in that language*. – Servy Oct 04 '16 at 17:35
  • 3
    @Servy Standard Scheme has `set!` for mutating a variable, but no stand-alone `!` operator. The convention exists because Lisp has a history of using symbols in identifiers to convey meaning due to very few restrictions on what a valid identifier is. The lack of restrictions exists due to Lisp's focus on macros and domain specific languages. – Jack Oct 04 '16 at 17:49
  • @Jack Thanks, I knew it was something along those lines and was hoping someone more familiar with the language would chime in. – Servy Oct 04 '16 at 17:51
  • 1
    Ruby also uses the `!` convention (eg. for `downcase` and `downcase!`), but it indicates "danger" more generally than "side effects". – Andrew Oct 04 '16 at 18:09
  • 1
    @AndrewPiliser: Specifically, it indicates the "more surprising" version of a *pair* of methods. There is never a bang method without a corresponding non-bang method. And it has nothing to do with side-effects. E.g. `Array#clear` mutates the receiver but doesn't have a bang, `Process::exit!` has a bang, but that bang doesn't denote side-effects, rather it denotes the fact that it skips running exit handlers, whereas `Process::exit` does run them normally. – Jörg W Mittag Oct 04 '16 at 20:39
  • Well, you already mentioned an existing naming convention, so why not use that? – Jörg W Mittag Oct 04 '16 at 20:40

3 Answers3

13

Follow command-query separation. Functions that return values don't have side effects, functions that have side effects don't return values.

It helps also to name functions that return values after the thing they return, i.e., a noun or adjective. While functions that have side-effects should be named after the effect they perform, i.e., a verb.

So for example myArray.sort() has a side effect, it sorts the array. Therefore it doesn't return anything and is named after a verb. Meanwhile, myArray.sorted() returns a sorted copy of myArray. Therefore it doesn't have any side effects and is named after the thing it returns.

FYI, the above idea (nouns/adjectives for pure functions and verbs for side-effect producing functions) is a standard in Swift 3.

Name functions and methods according to their side-effects

  • Those without side-effects should read as noun phrases.
  • Those with side-effects should read as imperative verb phrases.

(https://swift.org/documentation/api-design-guidelines/#strive-for-fluent-usage)

Daniel T.
  • 3,013
  • 19
  • 24
5

The fundamental problem is that side-effects are not captured in the type system. Using a function-naming convention is a poor substitute for static verification. There are a few ways around this.

Haskell uses monads to capture side-effects within a context. The monadic bind operation composes impure functions much as the normal function composition operator composes pure functions. The monad laws ensures this operator acts analogously to regular composition.

Another route is to separate pure from impure by separating expressions from commands entirely. These are two entirely different syntactic categories that cannot be mixed. Expressions have types that allow us to compose terms. An expression, by definition, cannot depend on any assignables (it has no access to the store). Commands do not have a type in the traditional sense, and cannot return a value. They can only interact with the program by mutating the store.

Note that conventionally type-safe, "functional" languages may not follow either of these paradigms. For example, OCaml and SML do not properly differentiate pure from impure functions.

Neither of these solutions is perfect, and this is still an active area of research.

gardenhead
  • 4,719
  • 2
  • 19
  • 24
  • note that haskell also has unsafePerformIO – jk. Oct 04 '16 at 16:36
  • I am not deeply familiar with Haskell. Most safe languages provide a way to subvert the type system as a last resort. Also, your username makes it hard for me to take anything you say seriously :D – gardenhead Oct 04 '16 at 17:00
  • @jk unsafePerformIO can be safely disregarded in this context. It's an escape hatch not meant to be used by regular code, and it comes with [significant caveats and warnings](http://hackage.haskell.org/package/base-4.9.0.0/docs/System-IO-Unsafe.html#v:unsafePerformIO). It must not be used with side-effecting code, anyway. – Andres F. Oct 04 '16 at 17:47
  • @AndresF. my point was that unsafe* is a naming convention for, well unsafe things in Haskell, which pretty much means things that themselves perform side effects, though its also only used by the implementation itself not by user code – jk. Oct 13 '16 at 09:16
4

Calling out methods or functions seems like a fantastic idea because it could help flush out times where code introduces a level of unsafety. Joel Spolsky delves into this idea quite a bit in his article Making Wrong Code Look Wrong (http://www.joelonsoftware.com/articles/Wrong.html) where he recommends using a less-commonly well known version of Hungarian notation to make certain ideas more transparent within the system.

The language to which you are referring is almost certainly Scheme (see http://download.plt-scheme.org/doc/html/guide/set_.html for an easy example). I am not aware of anything global.

Java prefixes property methods with get and set to partially fulfill this purpose, but I am not really aware of any common conventions of the sort you mention outside the Lisp world that are not (as @gardenhead pointed out) embedded in the type system.

I think, in the main, you are pretty safe creating a style guideline for your team, particularly if you deal in something with a lot of concurrency where side-effects are even more dangerous than commonly.

For whatever it is worth, I can think of a couple of ways to implement this in ALGOL-esque languages. A simple one might be a prefix, as quasi-suggested by Spolsky - say s_ for stateful operations and l_ for stateless operations.

A more modern idea might be to put words as prefixes or suffixes. Maybe calculate is a pure function but mutateCalculation is the impure one.

Finally, there is a degree to which a lot of this should be handled by separation of concerns - only the layer that updates the database should be capable of updating the database for example. In that case, it is pretty obvious that you have to worry about side effects in stateful layers.

Michael
  • 6,437
  • 2
  • 25
  • 34
  • Thanks for the response. I agree that in an ideal world this should be mostly handled by separation of concerns. My primary use case for a naming convention is in picking apart and refactoring old code which was not necessarily written with elegance and best practices in mind! (maybe sometimes by myself back in the day before I got religion!) – Roger Heathcote Oct 13 '16 at 09:16
  • Oh and that Joel Spolsky article is fantastic, thanks for the link! – Roger Heathcote Oct 13 '16 at 09:19