Sometimes a labeled break or continue can make code a lot more readable.
OUTERLOOP: for ( ;/*stuff*/; ) {
//...lots of code
if ( isEnough() ) break
The convention I've most seen is simply camel case, like a method name...
myLabel:
but I've also seen labels prefixed with an underscore
_myLabel:
or with lab...
labSomething:
You can probably sense though from the other answers that you'll be hard-pushed to find a coding standard that says anything other than 'Don't use labels'. The answer then I guess is that you should use whatever style makes sense to you, as long as it's consistent.
The convention is to avoid labels altogether.
There are very, very few valid reasons to use a label for breaking out of a loop. Breaking out is ok, but you can remove the need to break at all by modifying your design a little. In the example you have given, you would extract the 'Lots of code' sections and put them in individual methods with meaningful names.
for ( ;/*stuff*/; )
{
lotsOfCode();
if ( !isEnough() )
{
moreCode();
}
}
Edit: having seen the actual code in question (over here), I think the use of labels is probably the best way to make the code readable. In most cases using labels is the wrong approach, in this instance, I think it is fine.
The convetion/best practise would still be not to use them at all and to refactor the code so that is more readable using extract as method.
They are kind of the goto of Java - not sure if C# has them. I have never used them in practice, I can't think of a case where avoiding them wouldn't result in much more readable code.
But if you have to- I think all caps is ok. Most people won't use labelled breaks, so when they see the code, the caps will jump out at them and will force them to realise what is going on.