C# style #region/#endregion preprocesssor directives for code organization

Topics: Language Specification
Dec 27, 2012 at 8:23 PM

It would be great to have the C# style #region/#endregion for code organization.

From my limited experience with JavaScript and TypeScript, it looks as if this would be even more useful than it is in C#.

Feb 1, 2013 at 12:47 PM
Edited Feb 1, 2013 at 12:54 PM
Just discovered that you can get support for regions by installing Web Essentials http://visualstudiogallery.msdn.microsoft.com/07d54d12-7133-4e15-becb-6f451ea3bea6
Feb 1, 2013 at 12:58 PM
NO NO NO NO NO!

The #region directive enables badly-organised code files, with thousands of lines of code in a single file.

This is not how you manage your code, people.

If you find yourself thinking "this is getting a little unwieldy, I'll wrap this code in a region", STOP, and refactor your code immediately. Break your massive class down into several smaller, Single-Responsibility classes. Make judicious use of inheritance. If you haven't got time to refactor right now, then live with it without the #region tag; eventually, you'll find the time.

Introducing #region directives into TypeScript will facilitate and encourage lazy programming, and create the same kind of unmaintainable code ghettos I spend far too much of my consulting time ripping apart in code reviews.

Please, please don't do this.
Feb 1, 2013 at 1:20 PM
It's also a workaround to collapsing functions, nested in class methods in TypeScript.
Feb 1, 2013 at 2:32 PM
Agree with @markrendle. Partial classes and #region/#endregions are both used to give the impression of succinct code - where no such thing exists.
Feb 1, 2013 at 2:46 PM
<div style="font-family:Calibri,'Segoe UI',Meiryo,'Microsoft YaHei UI','Microsoft JhengHei UI','Malgun Gothic','Khmer UI','Nirmala UI',Tunga,'Lao UI',Ebrima,sans-serif; font-size:16px"> <div>I’ve written quite a lot of code over the years and sometimes you end up with large classes no matter what and I’m especially fond of partial classes and #regions to group for example the implementation of an interface. Let’s say a class needs to implement interface A, B and C, then I tend to place each interface implementation in either a partial class file or in a region. One convenient benefit of placing an interface implementation in a partial class file is that when you need to add the interface to another class, you just copy and paste the file.</div> <div>Just my 2 cents,</div> <div>---bjorn</div> <div></div> <div> <div></div> <div></div> </div> <div style="border-top-color:rgb(225,225,225); border-top-width:1px; border-top-style:solid"> <strong>From:</strong> nabog<br> <strong>Sent:</strong> ‎February‎ ‎1‎, ‎2013 ‎7‎:‎32‎ ‎AM<br> <strong>To:</strong> bjorn@backlund.org<br> <strong>Subject:</strong> Re: C# style #region/#endregion preprocesssor directives for code organization [typescript:427845]<br> </div> <div></div> <p>From: nabog</p> <div id="ThreadNotificationPostBody">Agree with @markrendle. Partial classes and #region/#endregions are both used to give the impression of succinct code - where no such thing exists.</div> </div>
Feb 1, 2013 at 7:20 PM
BjornBacklund wrote:
...you just copy and paste...

I rest my case.
Feb 1, 2013 at 7:23 PM
pingec wrote:
It's also a workaround to collapsing functions, nested in class methods in TypeScript.
So what's really needed is support for collapsing functions nested in class methods in the IDE.
Feb 1, 2013 at 8:37 PM
<div style="font-family:Calibri,'Segoe UI',Meiryo,'Microsoft YaHei UI','Microsoft JhengHei UI','Malgun Gothic','Khmer UI','Nirmala UI',Tunga,'Lao UI',Ebrima,sans-serif; font-size:16px"> <div>And comments like this is productive?</div> <div>The copy/paste allows me to be more productive and what I’m looking for in a tool is how more productive I can be, it’s all about getting the job done faster and better. Isolating an interface in a partial class file makes perfect sense, if you need to add the interface to another class, you just copy/paste the file and you have a perfect template for all the methods, my experience is that in many cases you only need to alter some of the methods. I would like TS to support all kinds of programming styles, my style is to keep source files small and to organize code using partial class files.</div> <div>Just my 2 cents...</div> <div>---bjorn</div> <div></div> <div></div> <div style="border-top-color:rgb(225,225,225); border-top-width:1px; border-top-style:solid"> <strong>From:</strong> markrendle<br> <strong>Sent:</strong> ‎February‎ ‎1‎, ‎2013 ‎12‎:‎20‎ ‎PM<br> <strong>To:</strong> bjorn@backlund.org<br> <strong>Subject:</strong> Re: C# style #region/#endregion preprocesssor directives for code organization [typescript:427845]<br> </div> <div></div> <p>From: markrendle</p> <div id="ThreadNotificationPostBody">**BjornBacklund wrote:** ...you just copy and paste... I rest my case.</div> </div>
Feb 1, 2013 at 10:16 PM
BjornBacklund wrote:
<div style="font-family:Calibri,'Segoe UI',Meiryo,'Microsoft YaHei UI','Microsoft JhengHei UI','Malgun Gothic','Khmer UI','Nirmala UI',Tunga,'Lao UI',Ebrima,sans-serif; font-size:16px"> <div>And comments like this is productive?</div> <div>The copy/paste allows me to be more productive and what I’m looking for in a tool is how more productive I can be, it’s all about getting the job done faster and better. Isolating an interface in a partial class file makes perfect sense, if you need to add the interface to another class, you just copy/paste the file and you have a perfect template for all the methods, my experience is that in many cases you only need to alter some of the methods. I would like TS to support all kinds of programming styles, my style is to keep source files small and to organize code using partial class files.</div> <div>Just my 2 cents...</div> <div>---bjorn</div> <div></div> <div></div> <div style="border-top-color:rgb(225,225,225); border-top-width:1px; border-top-style:solid"> <strong>From:</strong> markrendle<br> <strong>Sent:</strong> ‎February‎ ‎1‎, ‎2013 ‎12‎:‎20‎ ‎PM<br> <strong>To:</strong> bjorn@backlund.org<br> <strong>Subject:</strong> Re: C# style #region/#endregion preprocesssor directives for code organization [typescript:427845]<br> </div> <div></div> <p>From: markrendle</p> <div id="ThreadNotificationPostBody">**BjornBacklund wrote:** ...you just copy and paste... I rest my case.</div> </div>
Why are Bjorn's posts all HTML source? Is everyone seeing that or is it just me?
Feb 1, 2013 at 10:17 PM
Edited Feb 1, 2013 at 10:22 PM
BjornBacklund wrote:
it’s all about getting the job done faster and better.
Faster, perhaps. Not better.

For the record, I often put complex interface implementations (e.g. IDictionary<TKey,TValue>) in separate files using partial classes in C#. I don't have a problem with partial classes in C# (except where they're used as a workaround to modify generated code, which is just evil), but adding them to TypeScript would break the ES6 compatibility rule.

The more important point here is that very large classes and code files should be rare exceptions, not something which is encouraged by language features.
Feb 2, 2013 at 7:48 AM
markrendle wrote:
  "This is not how you manage your code, people."
Well someone needs to tell Microsoft (TypeScript-Source-Code), and JQuery, and KnockoutJS that they're doing it all wrong.
They all place thousands of lines of TypeScript and JavaScript code in single files.

Deep hierarchies may be satisfactory in C#, but the deep prototype chains this would produce in TypeScript (JavaScript) would create serious performance issues.
Concatenating hundreds of small files in the current release of TypeScript is a maintenance nightmare as file reference comments and HTML script tags must be manually maintained.

I agree that 'Single-Responsibility classes' represent good design, but there's currently no advantage to placing each class in its own file.
A file per namespace (module) may be justified, but the overhead of hundreds of files is not justified in TypeScript as it is in C#.

Anyone who has studied the TypeScript source code could agree that collapsible regions might enhance the learning experience.
The TypeScript parser (parser.ts), is currently 4,412 lines of code. This file contains only two interfaces, two classes, and two Enums.
The exported 'Parser' class in this file, is over 4,300 lines of code.
I can only assume that the authors of the language would use best practices in the actual product development.

As a C# developer, I use folder-per-namespace and file-per-class, and I still use regions to organize properties, constructors, and methods in each class-file. I have developed and currently maintain several commercial products that are hundreds of thousands of lines of C#/XAML code, and I have never regretted the use of regions.
Feb 2, 2013 at 9:54 AM
Projects like TypeScript and jQuery are the exception, not the rule. I have massive classes in projects where it's unavoidable not to, but wherever possible I achieve "code organisation" by organising my code into classes and files like the gods intended.

I'd love to see more support for good code organisation in TypeScript: collapsible class methods in editors; partial or additive classes; mixins; inlining/collapsing inheritance; that sort of thing.

Regions ain't it, though.
Feb 3, 2013 at 3:08 PM
@nhrones,

From your description the #regions appear to be used correctly in your projects. How will you guarantee that no one in your company will abuse them?

The JQuery and Knockout JS libraries are probably not the way one would want to write in-house code. They are not maintainable except by small groups of dedicated people who have (or will) work on them for a number of years. In a commercial environment people come and go and the code-base tends to be larger.

I wonder if someone from TypeScript will tell us of the benefit of organising their code in this manner? 4K lines of code for 2 classes? Blimey!

Also it appears the entire TypeScript code-base is in one monolithic project, with large numbers of files in a labyrinth of deeply nested folders. Why not break this up into multiple projects?
Feb 3, 2013 at 10:57 PM
We must keep In mind that this is relatively 'new' territory. I'm preparing to move a number of C#/Silverlight smart-client applications, to HTML5 technologies. This browser-based smart-client application architecture, where most of the client UI and logic lives on the client, is as new as DART and TypeScript are. This is what is driving the need for these new compiler technologies ... code management, reuse and organization.
My point about the typical, 'SUCSESSFUL', JavaScript library being monolithic in nature, goes to the reason that Facebook failed to produce effective Mobile-Web applications ... they used a modular development architecture to such an extreme that performance became unacceptable.
We need 'NEW' techniques for code management that provide the benefits of modularization and 'Single-Responsibility' code elements (I've yet to be convinced that the 'classical' approach is relevant to a JavaScript compiler), without sacrificing JavaScript performance.
TypeScript itself is not a trivial application, and yet it lives in a single namespace (object). The goal of the developer's, I'm sure, was to keep scope and prototype chains as shallow as possible. Hierarchy levels in JavaScript can induce orders of magnitude performance penalties. After all, this is not 'you're fathers C#'!
Perhaps the DART team has the correct response to this issue, a VM to overcome the glaring deficiencies in JavaScript. Again, Dart's 'import', 'part', and 'library' directives (See: Dart Package Manager), encourage modularization and code reuse with minimal impact on VM efficiency.
One can only hope that Microsoft my also follow up with an Open-Source TypeScript VM to eventually replace Silverlight.

Anyway, let's all thank Mads for adding //#region to Web Essentials and close this discussion.
Feb 3, 2013 at 11:50 PM
nhrones wrote:
Anyway, let's all thank Mads for adding //#region to Web Essentials and close this discussion.
Amen to that.
Mar 12, 2015 at 10:49 PM
Ooh, another fundamentalist religious code style discussion. Cool! :)
I like sprinkling #regions all over the place and have been doing it for 10+ years. I find it helps me more often than it introduces any problems other than occasionally falling into religious debates with people who hate on other people for seeing things differently. I can see risks from misusing #regions, but I also see risks from driving over other people in a car and yet I don't see many people saying we shouldn't drive.
Mar 12, 2015 at 11:06 PM
xyzzer wrote:
I can see risks from misusing #regions, but I also see risks from driving over other people in a car and yet I don't see many people saying we shouldn't drive.
I thought this discussion was done :(

The car analogy here is, as always, silly. Yes, you can kill someone by driving over them in a car, but that is a reason to make it harder to do that in cars, not to add vehicular homicide functionality to electric scooters.
Mar 12, 2015 at 11:18 PM
Edited Mar 12, 2015 at 11:19 PM
It was done for a while, but now it's continued. Religious discussions have no possible end! :)
#regions don't have a built-in "hide bad code" feature. It's a side effect that they enable it.
There are possibly other ways to hide bad code like... prefixing it with a very long indentation.
See, even "goto" has its good uses. There is no bad language feature. There is bad language use ... which also can depend on context.
If I swear in the confines of my office and no one hears that - it helps me relieve stress. If swear words were not made available - I couldn't teach them to my children, but I might also end up dying prematurely because of the built-up stress.