I guess there are differing approaches here. I’m working on a PHP module for Drupal at the moment, and my main file is ~2500 lines long. As I’m using Emacs, I split it up into sections delimited with a special comment beginning ‘///’ (instead of the normal ‘//’ it takes to begin a line comment in PHP), set outline-regexp to ^/// and use outline-minor-mode. This becomes an extremely light-weight form of folding (those section-delimiting comments would probably be there anyway) and makes the length manageable.
I guess your solution here would be to put each section, or a few closely linked sections, into a new file. This is feasible but I find it quicker to use folding compared to switching between different files.
You mean you have to add something to code to accomplish this folding?
IntelliJ is an IDE that can manage by itself for Java. No additions to code necessary. And the foldings are open by default; you have to manually close them to get the code to disappear.
Maybe Visual Studio can learn something from IntelliJ.
Now, this is interesting, because I tend to use #region more to HIDE THE CRAP (XML documentation etc, long list of attributes etc.) making it easier to see the important code…
I do tend to roll up the properties as well. Since 99% of the time the getters/setters aren’t really doing much in themselves.
e.g.
#region Attributes
[Browsable(false)]
[MergableProperty(false)]
[DefaultValue(null)]
[PersistenceMode(PersistenceMode.InnerProperty)]
[TemplateContainer(typeof(MyType))]
[TemplateInstance(TemplateInstance.Single)]
#endregion
public ITemplate ContentTemplate
{
get { return _temp; }
set { _temp = value; }
}
Becomes:
Attributes
public ITemplate ContentTemplate
{
get { return _temp; }
set { _temp = value; }
}
As ever I guess you’ve just managed to get yourself in just another conflicting topic.
I’m a big fan of code region, they actually help organizing my code. The fact that something can be over used where there’s no need doesn’t make it bad. You can put a comment on every single line of code so, should we stop using code comments since they can be potentially harmful?
Regions must be used when you can easily delimit aspects or functionality, they provide semantical separation into a unit. I prefer them (a lot) over partial classes.
If you have one constructor then DO NOT surround it with a region, but maybe you have 6 different constructors. In that case, surrounding them with a region allows for any developer to say I don’t really need to see the constructor code right now, let’s take it out of the picture.
It is not about protected region, override regions … that might or might not be useful but I personally use them with things like message processing methods or minor helpers or stream handling routines and so on… It all dependes on what you’re coding, if it is long enough but it must still be part of the same file then regions can help organizing the code in a semantical way.
I know the examples may be naive and there will be someone that will point out you can put message methods in a different class and blah… but in real projects some times just doesn’t make sense to refactor a class to keep it size small at the prize of coupling increase or a more complex flow of messages between classes.
If the source file -needs- folding, there is a problem. Extract Class refactoring should be happening (accomplish hiding by design, not by editor directives).
The example file weighs in at ~300 lines. I don’t think folding was required.
Wait a sec: 1/3 lines are public static methods? Doh!
@JetBrain: All modern environments have code folding–it’s useless.
I hadn’t heard of the #region before, but I like the concept a little bit, it lets you give a meaningful comment to your region.
I always wondered what it would be like having an environment that primarily showed comments–where code was more like comments, and comments were what people actually looked at when they were looking through the code base.
Overall, without the structure imposed on us by actual code syntax, I think it would be an utter mess–but it’s an interesting concept.
Also, considering the pro comments I’d say that Jeff was absolutely on with his thoughts on rather than hide the garbage under the rug, get rid of the garbage.
Every justification I see here is either Legacy, we know it’s garbage, data or junk-code like getters setters.
Extracting any of those from your code can only lead to goodness (and be very liberal with the definition of data, virtually ANY Ascii strings, HTML, menu/GUI text, regex expressions… anything that isn’t actually procedural code shouldn’t be in your code.)
Add to that the obvious–eliminate and completely refactor (don’t just cut in half) any method that is more than a screen long, and any objects that do more than one thing.
I actually feel strongly enough about this one to comment.
I use the ‘buckets’ to hide a lot of rubbish in. Fortunately everyone in my team actually knows the Ctrl+M, Ctrl+L combo (Expand all blocks in the file).
I definitely see your point, but you should see the rubbish legacy code that we inherit (1000s of lines per class, sometimes even per method). First thing we do is put some regions in to allow the class to become browsable again.
Now, ideal - perfectly written - code should never need this, you are right. One day I hope to work in an environment that produces such code.
I actually feel strongly enough about this one to comment.
I use the ‘buckets’ to hide a lot of rubbish in. Fortunately everyone in my team actually knows the Ctrl+M, Ctrl+L combo (Expand all blocks in the file).
I definitely see your point, but you should see the rubbish legacy code that we inherit (1000s of lines per class, sometimes even per method). First thing we do is put some regions in to allow the class to become browsable again.
Now, ideal - perfectly written - code should never need this, you are right. One day I hope to work in an environment that produces such code.
I used to be one of those who regioned everything. Fields, Constructors, Properties, Public Methods, etc. I thought I was doing something to organize the code. I knew where everything was, so it must be good! Only when I started seeing code like in your example (and even worse, when people nest the damned regions) did I realize my mistake. I was making regions that were good for me, and nobody else. It was how I organized the various parts of the code in my head, and most people had a tough time getting through it at first, if ever.
Still, I think regions can be good to hide large blocks of comments (as was previously mentioned) and I still ascribe to the Microsoft standard/default of putting a region around an interface implementation. That particular usage is common and frankly I’ve gotten used to it.
What’s all the fuss about? If you don’t like it why… then you don’t have to
Have to agree with people that in certain cases it makes code easier to maintain/read especially when you’re dropping into code you didn’t write yourself to fix bugs/add features.
If there is something that makes code unreadable/unmaintainable then it is partial classes! At least with #region you have all your code in the SAME FILE.
And the foldings are open by default; you have to manually close them to get the code to disappear.
In the base configuration, but you can set your IDE to auto-collapse by code block type (file headers, imports, javadoc comments, method bodies, annotations, getterssetters, inner classes, anonymous classes and xml tags)
If you’re constantly editing one small area of a giant file, why isn’t the part that changes frequently in a different file?
If your changing one aspect all of the time, yeah you should put it in a different file.
But if you’re adding new features, to, lets say, a game. You’ll go into an input object to add something. Or you’ll go into a graphics object to add something.
These are files that you would likely be modifying to add new features that wouldn’t necessarily warrant a completely new class. Having those regions would save some strain on the fingers and the eyeballs.
Use CTRL+I incremental search. You only see what you find as you type.
Even though I strongly disagree, I feel these are great to organize code…it’s nice to hear a differing view and we should be cautious so we don’t abuse them as in your example above.
