Live data from Hacker News

Windows CoreAudio API in C#

hardkjarni.blogspot.com

11–20 of 30 posts

Re: Windows CoreAudio API in C#

#11

The code is well structured and easy to read. Thanks for the example. Random aside: Why do so many C# coders use #region/#endregion? It really seems like a bad habit that discourages otherwise good coders from splitting their code into logical OOP silos and instead they dump too much code into a single file, and then use regions to regain some kind of order... Regions are like goto in that they don't within their own…

I think regions are super useful. Even within the context of a class, I create regions for various types of code, e.g., constructors, private fields, etc...

I'm not sure how regions change how you create your class hierarchies and such. One of the first things I do when I inherit a project, is I add regions to it. I'm not changing the class hierarchies, but I am making it a lot easier to navigate within Visual Studio.

Re: Windows CoreAudio API in C#

#12

The code is well structured and easy to read. Thanks for the example. Random aside: Why do so many C# coders use #region/#endregion? It really seems like a bad habit that discourages otherwise good coders from splitting their code into logical OOP silos and instead they dump too much code into a single file, and then use regions to regain some kind of order... Regions are like goto in that they don't within their own…

I think regions are super useful. Even within the context of a class, I create regions for various types of code, e.g., constructors, private fields, etc... I'm not sure how regions change how you create your class hierarchies and such. One of the first things I do when I inherit a project, is I add regions to it. I'm not changing the class hierarchies, but I am making it a lot easier to navigate within Visual Studio…

I don't see how hiding large chunks of code behind a drop-down is making it "easier to navigate in Visual Studio." If anything it is now much harder.

Plus you're now burying how long your class is and the individual methods within. So a class or method that would otherwise be inappropriately long now looks a reasonable length.

If you feel like the code is so long that it needs regions, then refactor the code, don't hide the mess under the bed.

Re: Windows CoreAudio API in C#

#13
post #10
post #9

Earlier quoted context omitted.

>older MVC apps (where the controllers get insane). Oh dear lord the MVC madness I've seen... thousand yard stare

I hear you. Seven year old MVC forms with five pages of inputs, backed up to a single forty column table via Entity Framework, and a controller with another five pages of arcane conditionals for binding and validations :|

Please stop, dear god the Entity Framework as well! This horror will keep me up all night now.. :/

Re: Windows CoreAudio API in C#

#14

The code is well structured and easy to read. Thanks for the example. Random aside: Why do so many C# coders use #region/#endregion? It really seems like a bad habit that discourages otherwise good coders from splitting their code into logical OOP silos and instead they dump too much code into a single file, and then use regions to regain some kind of order... Regions are like goto in that they don't within their own…

> discourages ... from splitting their code into logical OOP silos

What you fail to see is those silos can be a prison. One of the worst experiences I consistently have with heavily "OOP-person" code is you come to a new source tree and there are so many little tiny do-nothing classes and interfaces in individually tiny insignificant files that you can't come fresh to the project and tell "where the meat is" by browsing the filesystem. Putting those smaller interfaces and glue in a few mid-sized thematically oriented source files can be a breath of fresh air relative to this.

Re: Windows CoreAudio API in C#

#15

The code is well structured and easy to read. Thanks for the example. Random aside: Why do so many C# coders use #region/#endregion? It really seems like a bad habit that discourages otherwise good coders from splitting their code into logical OOP silos and instead they dump too much code into a single file, and then use regions to regain some kind of order... Regions are like goto in that they don't within their own…

> discourages ... from splitting their code into logical OOP silos What you fail to see is those silos can be a prison. One of the worst experiences I consistently have with heavily "OOP-person" code is you come to a new source tree and there are so many little tiny do-nothing classes and interfaces in individually tiny insignificant files that you can't come fresh to the project and tell "where the meat is" by brows…

Exactly this. There is a fine line with regions and they have their uses.

As an example, I was working on a project a while back that had StyleCop rules set up so stringently that nothing could live in the same file, no enums, structs, extension methods, nada. The amount of files you had to create when adding new functionality (even a minor one) was mind boggling...

Re: Windows CoreAudio API in C#

#16

The code is well structured and easy to read. Thanks for the example. Random aside: Why do so many C# coders use #region/#endregion? It really seems like a bad habit that discourages otherwise good coders from splitting their code into logical OOP silos and instead they dump too much code into a single file, and then use regions to regain some kind of order... Regions are like goto in that they don't within their own…

I think regions are super useful. Even within the context of a class, I create regions for various types of code, e.g., constructors, private fields, etc... I'm not sure how regions change how you create your class hierarchies and such. One of the first things I do when I inherit a project, is I add regions to it. I'm not changing the class hierarchies, but I am making it a lot easier to navigate within Visual Studio…

Ugh. Every time I inherit code that someone has peppered with regions, I delete then. It's a bunch of extra noise if you expand all regions, and if they're collapsed it's harder to see the overall structure of the code, and some functionality (specifically undo/redo, but others also) gets gimpy when collapsed regions are involved, making it hard to see what is changing.

I find regions to be useful 1% of the time, simply pointless 10% of the time, and hiding crappy code the other 89% of the time. When I open up code and see a bunch of regions, I immediately assume that the file contains way too much unrelated functionality and that the code is poorly written. This assumption is very rarely wrong.

Re: Windows CoreAudio API in C#

#17

The code is well structured and easy to read. Thanks for the example. Random aside: Why do so many C# coders use #region/#endregion? It really seems like a bad habit that discourages otherwise good coders from splitting their code into logical OOP silos and instead they dump too much code into a single file, and then use regions to regain some kind of order... Regions are like goto in that they don't within their own…

> discourages ... from splitting their code into logical OOP silos What you fail to see is those silos can be a prison. One of the worst experiences I consistently have with heavily "OOP-person" code is you come to a new source tree and there are so many little tiny do-nothing classes and interfaces in individually tiny insignificant files that you can't come fresh to the project and tell "where the meat is" by brows…

I feel like in languages like this you shouldn't even be using filesystem to browse the code but jump in to IDE visualization tools (hopefully there are architectural docs with this stuff outlined, but if not I just look at stuff like class diagrams)

Re: Windows CoreAudio API in C#

#18

The code is well structured and easy to read. Thanks for the example. Random aside: Why do so many C# coders use #region/#endregion? It really seems like a bad habit that discourages otherwise good coders from splitting their code into logical OOP silos and instead they dump too much code into a single file, and then use regions to regain some kind of order... Regions are like goto in that they don't within their own…

I went looking around for other opinions after leaving my other answer and found this SO question. You might be interested in glancing over it: http://programmers.stackexchange.com/questions/53086/are-reg...

It made me rethink a few of the ways I've used regions previously. As a stopgap for refactoring legacy code, though, I'm still not 100% sold.

Like a lot of articles here, the comments and the back and forth are as interesting as the answer. I think right now I'd say that, used carefully, there's nothing implicitly wrong with regions, but overall it's probably better to avoid them. Honestly, I'll probably have to do a little more digging and see where it comes out.

They're reminding me of comments in general at this point, where there's nothing implicitly wrong with them, but every time you write one you should be asking yourself if you could clearly bake that intention/information into the code itself.

Re: Windows CoreAudio API in C#

#19

Earlier quoted context omitted.

I think regions are super useful. Even within the context of a class, I create regions for various types of code, e.g., constructors, private fields, etc... I'm not sure how regions change how you create your class hierarchies and such. One of the first things I do when I inherit a project, is I add regions to it. I'm not changing the class hierarchies, but I am making it a lot easier to navigate within Visual Studio…

I don't see how hiding large chunks of code behind a drop-down is making it "easier to navigate in Visual Studio." If anything it is now much harder. Plus you're now burying how long your class is and the individual methods within. So a class or method that would otherwise be inappropriately long now looks a reasonable length. If you feel like the code is so long that it needs regions, then refactor the code, don't h…

I can't speak for the gp, but they were talking about inheriting a project/legacy code.

If I end up needing to go through legacy code, and there are a lot of gnarly, long methods/blocks, I'll usually add comments and regions to it as I go along. I'll use comments if I just want to note something, and a region if I want to note something about a region of code. It's my rough map. Being able to tell Visual Studio to arbitrarily collapse an area is handy for sketching it. The long term goal is to refactor, but it's handy as a way to quickly outline things.

Re: Windows CoreAudio API in C#

#20
post #16

Earlier quoted context omitted.

I think regions are super useful. Even within the context of a class, I create regions for various types of code, e.g., constructors, private fields, etc... I'm not sure how regions change how you create your class hierarchies and such. One of the first things I do when I inherit a project, is I add regions to it. I'm not changing the class hierarchies, but I am making it a lot easier to navigate within Visual Studio…

Ugh. Every time I inherit code that someone has peppered with regions, I delete then. It's a bunch of extra noise if you expand all regions, and if they're collapsed it's harder to see the overall structure of the code, and some functionality (specifically undo/redo, but others also) gets gimpy when collapsed regions are involved, making it hard to see what is changing. I find regions to be useful 1% of the time, sim…

   ca82a6d - kenjackson - 10 files changed, 34 insertions: "Added some regions"
   085bb3b - dpark - 10 files changed, 34 deletions: "Removed regions"
   a11bef0 - kenjackson - 10 files changed, 34 insertions: "Added some regions"
   2432f8e - dpark - 10 files changed, 34 deletions: "Removed regions"
   cbe6306 - kenjackson - 10 files changed, 34 insertions: "Added some regions"
   e7e1bef - dpark - 10 files changed, 34 deletions: "Removed regions"
   ....
Post reply on HN