Maximum number of op_codes in script Is there any part of the Bitcoin protocol that established a limit on the maximum number of op_codes in a script.

Recently I have hit the limit for the bitcoin core client. In:
https://github.com/bitcoin/bitcoin/blob/ce56f5621a94dcc2159ebe57e43da727eab18e6c/src/script/interpreter.cpp
in line 276 you find:

   if (opcode &gt; OP_16 &amp;&amp; ++nOpCount &gt; 201)
        return set_error(serror, SCRIPT_ERR_OP_COUNT);*


I interpret this line as saying that, outside standard type of transactions, there is a limit to 201 operations beside pushing a number from 0 to 16 to the stack. 

Is this defined in any part of the protocol or discussed in any BIP?

I know there are limits for multiscript transactions:
https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#520byte_limitation_on_serialized_script_size
and that the number of signatures should be limited to avoid certain attacks, but for lightweight operations (OP_ADD and the like) I cannot find any explanation on the limit and the exact 201 value.

P.S: I found the error when trying to spend the offending script. Curiously, I was allowed to send the transaction. It is when the client tries to verify the data for the next transaction when there is a problem.
Most if not all constants like that are not described, documented or otherwise discussed. For the most part the Bitcoin Core code is the reference which everything else follows, rather than the code trying to conform to any sort of standard. If it were hinged on a particular piece of documentation the network would need to be hard forked every time there was a new behavior found that didn't meet the specification. 

201 operations is indeed the limit, and there is also a hard limit on the number of signature verifications that can occur in a block as well. Of all things in Bitcoin the script engine is probably the least well documented of all and has a number of oddities, partly due to its late inclusion.


  It is when the client tries to verify the data for the next transaction when there is a problem.


You can make all sorts of completely invalid output scripts, because as you have found, there's no validity checks on them until they are spent. It is up to the author of non standard scripts to understand the system and not render their coins un-spendable. If you don't understand it, try these things out on testnet3 before you lose real money to them.