I have to admit it, symbols suck, but since Regionerate operates on a syntactic level, it has no other way to determine which regions are existing, hand-crafted regions and which regions are Regionerated ones.
I’m pretty sure no-one really liked having “[rgn]” in front of Regionerated region declarations. Most users hated it but kept it, some users hated it and changed it to something minimal such as “*” while other users hated it and changed it to an empty string. (which caused trouble with comments and existing regions)
So I’ve decided to put a stop to it and kill the region symbol and allow Regionerate to operate without it. I wouldn’t have been able to do so if I wouldn’t have found this cheap trick: I just use ASCII character #255 instead of spaces.
ASCII character #255 (a.k.a. “The Hidden Dragon”) looks exactly like space and allows Regionerate to differentiate Regionerated regions from existing regions.
You can think of this as a hard-coded invisible symbol.
Take a look at this example:
1: #region Fields
2:
3: ...
4:
5: #endregion
6:
7: #region My Stuff
8:
9: ...
10:
11: #endregion
Even though these regions look the same, the first region is a Regionerated region and the latter is an existing region. How can I tell? The first one has the hidden dragon right after “#region” and “#endregion” (” “) and the second one has space (” “).
Crazy workaround, but it works. Anyway, this should be available on v0.6.6.5.
Regarding migration: New users will enjoy this the first time they Regionerate their code. However, users of versions prior to v0.6.6.5 might find this a bit annoying as Regionerate will treat symbolized regions as existing regions, causing code not to be Regionerated.
I can add some functionality to allow easier migration in v0.6.6.5 (something like a definition for “dead symbols” in the Code Layout document which will allow users to enter their old symbols, so Regionerate will automatically kill those), However this might take me some time and will delay this version.
The faster option will be to get rid of symbolized regions by a simple regular expression search & replace throughout the code. This will be a one-time task and should complete in a minute or two.
What do you think? Should I postpone this version for this one-time migration function or will you guys survive the regular expression search & replace? (I’ll post a short guide for you folks who aren’t familiar with regular expressions)
Please gimme your opinions on this before I continue. Thanks!
I wonder how will ReSharper’s “Reformat code…” affect that.
. Now it’s not that obvious, but I guess I’ll just have to use this for a while to have my own opinion on that.
I have mixed feelings about this one. On one hand, it seems more concise and clean, but on the other it relies on a hack, and as such is fragile. I also kind of liked that [rgn]. It was clear at first glance which regions are automatic, and which I created manually (most often with some profound reason
Posted by Krzysztof Koźmic on September 20th, 2007 8:23 am
You should give us the opportunity to live-test it, so can we please have a download of a version of RGN with this feature enabled?
Posted by Anonymous on September 20th, 2007 9:20 am
Krzysztof,
I don’t have ReSharper installed at home but I know it is installed in a company I do some consulting work in, so I’ll check if it is compatible the next time I visit there. Thanks for the warning.
Regarding [rgn], well, you can always set the Title attribute (under CreateRegion) to start with “[rgn]”
Posted by Omer Rauchwerger on September 20th, 2007 10:49 am
The symbol is only a mild annoyance. I’d much rather have it in plain view than having a “hidden” character in my code.
Posted by Gavin T.D. Greig on September 20th, 2007 12:13 pm
Anonymous,
I’ll release v0.6.6.5 with this feature and wait for feedback.
In the worst case, I’ll rollback the changes.
Posted by Omer Rauchwerger on September 20th, 2007 1:50 pm
ggreig,
Good to hear that, I guess I will have to find a hybrid solution that will allow people to choose between symbols and hidden dragons.
Thank you for your feedback.
Posted by Omer Rauchwerger on September 20th, 2007 1:51 pm
krzystof and gavin pretty much sum up my thoughts and concerns (except that I don’t see the symbol as an annoyance). When I see the [rgn] I have certain expectations of the code, prefixing the title will provide the same benefits though. If you need some one to test out compatibility with resharper (2.5x) let me know.
As to the original question. I would prefer to have the code in the layout. This moves the burden of remembering which projects have been regionerated with the new version and which ones I need to deregionerate and re-regionerate. This task will become more onerous if I add a [rgn] prefix to the title, as I wont know which regions use the prefix as a symbol and which use it for nothing.
Posted by Eric on September 20th, 2007 3:33 pm
I think there are really only two possible drawbacks:
1) It may not play nicely with other region-oriented refactoring products. For example, the DevExpress Refactor! product allows you to specify a region that it will extract a variable out to. Not a showstopper; you could just tell it not to worry about regions and then run Regionerate to handle it.
2) Not sure how code reformatters will work with it. Even something as simple as Ctrl+K, Ctrl+F where it removes whitespace from the end of lines… would it remove that hidden character? I think the larger risk is here.
I hope it works; if it does, it’ll rock.
Posted by Travis on September 20th, 2007 5:36 pm
Another idea: It sounds sort of picky, but being able to WRAP a region name would make a visible markup more aesthetically pleasing than prefixing with a known thing.
For example, if I could wrap my regions in brackets, like:
#region [My Region]
That would be better (and look more natural) than having just a prefix. Might be interesting to be able to define the leading and trailing strings so you could do:
#region *** My Region ***
#region “My Region”
#region — My Region ———-
… or any other number of things.
Posted by Travis on September 20th, 2007 5:39 pm
Whatever you use to mark Regionerated regions, it needs to be visible for all of the reasons that everyone else has mentioned.
I think Travis is onto something, in that it would be very nice if one could configure regionerate with an arbitrary prefix and/or a suffix. This would allow people to pick something that won’t collide with anything already in their codebase, and the option to use both a prefix and a suffix would result in regions a lot like I’ve seen people writing by hand in more than a few projects, making the results a bit less jarring than seeing something regionerate-specific.
Posted by Anonymous on September 21st, 2007 8:03 pm
Guys,
Thank you very much for your comments. They’ve helped me realize that making this change is a bit hasty and further thinking is necessary.
I’ll post another suggestion soon, and would love to hear your feedback on it.
Thanks again.
Posted by Omer Rauchwerger on September 22nd, 2007 2:34 pm
Read the follow up.
Posted by Omer Rauchwerger on September 23rd, 2007 7:37 pm