[jbenoit]

1. The author links to this file as an example: https://github.com/Semantic-Org/Semantic-UI/blob/49b9cbf47c1... . How would you structure it better than it currently is without using sections?

2. So you have a class that has a bunch of getters and setters. Let's just assume that "generate them automatically" is not an option. You want to make it really easy to see the part of the class which is getters, and the part of the class which is setters, and then skim past that. How do you do it?

3. So you have a file that defines 3 data structures. Each data structure has a definition, a bunch of functions for parsing it, and a bunch of functions for serializing it. The author suggests that you split the file into 3 sections for the types, with subsections each for the definition, parsing, and serializing. How would you do it? Let's say the language is Rust or Typescript.

[jaggederest]

> 1. The author links to this file as an example: https://github.com/Semantic-Org/Semantic-UI/blob/49b9cbf47c1... . How would you structure it better than it currently is without using sections?

Dear God it's a 3300 line file. Any way but one long 3300 line file is a significant improvement. I'm being hyperbolic but seriously, instead of button.less it should be deduplicated (less can be much less verbose, pun intended) and be a button directory with several subcomponents in it, like each top level heading. Less is a serious language that you should use the semantic features to organize your code instead of just comments.

> So you have a class that has a bunch of getters and setters. Let's just assume that "generate them automatically" is not an option. You want to make it really easy to see the part of the class which is getters, and the part of the class which is setters, and then skim past that. How do you do it?

You put it into a getters file and import it into the parent class. Almost every language has features for this. Or you put each attribute into its own file, if any of the getters and setters has smarter logic than just x = parameters[x]. Ideally you build classes that don't have so many attributes that it's difficult to scroll past the getters/setters in the first place - N > 8 is a significant warning sign the code needs to be split unless it's a configuration class or equivalent.

> So you have a file that defines 3 data structures. Each data structure has a definition, a bunch of functions for parsing it, and a bunch of functions for serializing it. The author suggests that you split the file into 3 sections for the types, with subsections each for the definition, parsing, and serializing. How would you do it? Let's say the language is Rust or Typescript.

It should definitely be in 3 files, possibly 3 folders, in Typescript: (/thing/index.ts, /thing/parsing.ts, /thing/serializing/json.ts) It's so marvelously easy to import things, you should be using modules amply to split up your code. Obviously the 10-lines-of-import-for-3-lines-of-code is too much, but seriously, imports are easy and cheap.

[norir]

> Dear God it's a 3300 line file. Any way but one long 3300 line file is a significant improvement.

I happily hack every day on a project that is self contained in a single 12K line (and growing) file. For me, splitting into multiple files would have negative utility. Everything is essentially in one place. I can find anything I need for my project with '/' search very quickly in vim.

My style is obviously not for everyone but it works great for me. I programmed for decades with traditional file splits and only in the last few years have I switched to single file. I have little interest in going back. For me, it is liberating to stop thinking about directory layout entirely. It also helps me to use simpler tools (I only use vim with no plugins) in part because I don't need help managing multiple files.

[jaggederest]

100% agree if it's your project it's your project. I'm just coming from the perspective of a very team-oriented style where you absolutely want to limit the complexity per file for understanding.

Also I don't envy you reviewing the diffs when you add something that affects e.g. indentation on the file.

[jbenoit]

> You put it into a getters file and import it into the parent class. Almost every language has features for this

Wait, what?

So you can do this in C/C++ for sure. #include is not just for imports. But Java? C#? How!

[tgittos]

C# at least supports the notion of partial classes that can have their definition spread over multiple files: https://learn.microsoft.com/en-us/dotnet/csharp/programming-...

Ruby has mixins and Python supports multiple inheritance. Go encourages composition over deep nested hierarchies.

Many main stream languages support this kind of functionality.

[jaggederest]

Superclasses, interfaces, or module import. I'm no Java or C# expert but you have to lean into the conventions the language provides. I would probably have a separate small POJO that stores the configuration for the class if it had so many getters/setters I wanted to split them out.

[chrismorgan]

At least some of the sectioning in that file would probably be better handled by leaning into the language more, doing things like nesting selectors.