+1  A: 

There is a convention for marking parameters in other languages (C++ specifically). When calling a method, mark parameters that will not be changed with const: e.g.

void doSomething( const int &parameter )
Steven Oxley
+2  A: 

I can only speak about the languages I've used, but... I'm not familiar with any such convention in Python, Perl, Java, PHP, Javascript, or Bash (shell) scripting.

Some programmers might find it useful to put some prefix or postfix on function names to indicate those that mutate their arguments vs. those that create new "versions" of the arguments and return them. If you're one of those people, go right ahead. But again, I'm not aware of anything standard (except for the const thing Steven mentioned in C and C++).

David Zaslavsky
+2  A: 

In Scheme, methods with side effects or methods that change the object passed as parameters have "!" as a postfix. Methods which are predicates have a "?". Other lisps also sometimes use this convention.

In Java, it's common to have the return type void for a procedure which mutates its receiver, and to return the computed value for a function which does not. ( eg: String.toLowerCase() returns a new string, Collections.sort(List) sorts in place and does not return a value ). However, this isn't a rigorous idiom, as often mutating procedures also need to return a value.

Pete Kirkham
+4  A: 

Bang methods are not intended to mean "changing the receiver".

http://www.wobblini.net/bang.txt

As you can see, Matz intended them to mean "more dangerous than the version without an exclamation mark". Just a general FYI, seeing most of the answers so far mentions changing the receiver.

August Lilleaas
I really think "more dangerous" was a cute way of saying "will change the receiver". All ruby code I've seen confirms this
Nice, now I know those methods are called "bang methods". I don't like the notion of "dangerous methods", though. Sounds very subjective to me.
panschk
Iraimbilanja: Not really, there are lots of methods that changes the receiver without a bang (e.g. Enumerable#delete_if). The point is that you should not have a bang method unless you have a none-bang equivalent. Changing the receiver alone is not enough to justify a bang.
August Lilleaas