#Making assumptions about language features

Unless you're writing a language-specific challenge, avoid terms specific to some class of languages, because these might not make sense for other languages and prevent them from participating. Languages can very different from what you're used to: functional, minimalist, graphical, untyped, strongly typed, and weird in many ways.

Examples of loaded phrases:

• "write a function that"
• "return a pointer to"
• "if the input is invalid, throw an exception"
• "at compile time"
• "you may not use the + operator."
• "if they are of different types"
• "modify the input object"

Usually, this can be fixed by using broader terms, but is sometimes is a sign of a problem with the challenge itself. Consider defining the requirements in terms of input and output without reference to the program internals.

Making assumptions about language features

Unless you're writing a language-specific challenge, avoid terms specific to some class of languages, because these might not make sense for other languages and prevent them from participating. Languages can very different from what you're used to: functional, minimalist, graphical, untyped, strongly typed, and weird in many ways.

Examples of loaded phrases:

• "write a function that"
• "return a pointer to"
• "if the input is invalid, throw an exception"
• "at compile time"
• "you may not use the + operator."
• "if they are of different types"
• "modify the input object"

Usually, this can be fixed by using broader terms, but is sometimes is a sign of a problem with the challenge itself. Consider defining the requirements in terms of input and output without reference to the program internals.