* moreover the main purpose of the rule is the following one: as soon as Enter() and Exit() statements are not called in the same method, fully understanding when those methods are really called at run time might be tricky, that's why we advise as a good practice to locate them in the same method. So for me, this rule more relates to a maintainability issue.
\[~ann.campbell.2] the code might be perfectly designed to be sure that method Enter() and Exit() are called as expected even when they are not located in the same method. But our rule engine is not smart enough to figure out when this is the case or not. That's why for me this rule relates to a coding best practice because by definition is they are not located in the same methods and even if the code is perfectly correct, this will require an extra effort for a developer to inject a change.
\[~ann.campbell.2] If we are anyway enforcing that the ``++Monitor.Enter()++`` and ``++Monitor.Exit()++`` calls should be done from the same method, then why not simply ban the direct usage of the ``++Monitor++`` class and force the usage ``++lock (...) {}++`` directives instead?
\[~ann.campbell.2] I would just change the recommended solution. And update the description saying that the easiest way of achieving the aim is to use the ``++lock++`` statement.
BTW the message and the descriptions seems to go after different things, and that is causing the confusion here. [~dinesh.bolkensteyn]?
\[~tamas.vajk] and [~dinesh.bolkensteyn] I've updated the description and compliant example. I've also moved the messages up from the Java subtask. See if they suit you better.