[HN Gopher] Should you split that file?
___________________________________________________________________
Should you split that file?
Author : vinipolicena
Score : 107 points
Date : 2023-12-01 17:33 UTC (5 hours ago)
(HTM) web link (www.pathsensitive.com)
(TXT) w3m dump (www.pathsensitive.com)
| jeffbee wrote:
| Some of this may be potentially true for TypeScript programmers.
| I have no idea, since I never used it. However, sensible division
| of code into small files can have enormous benefits in C++.
| Throwing everything into giant files makes it annoying to write
| and run unit tests, or to reuse part of the code in a new
| translation unit. There is a noticeable difference between
| working in a code base where the tests link and run in
| milliseconds, compared to ones where it takes a long time to
| compile and link them.
| tadfisher wrote:
| One of the best improvements in Kotlin (over Java) is the ability
| to have multiple top-level classes, functions, and static
| variables in one file. I hate jumping between 10 files when
| reviewing code.
|
| You technically can do this in plain Java, but it comes with many
| caveats and probably won't work with a default build setup. And
| no, nested classes are not the same thing.
| beeboobaa wrote:
| > And no, nested classes are not the same thing.
|
| They actually are if they're public static. Quite literally so,
| nested static classes are the exact same as "normal" classes
| but named `OuterName$InnerName.class`
| occz wrote:
| It might be for the compiler, but the nesting implies
| hierarchy for the reader, which may or may not be desirable.
| beeboobaa wrote:
| Same goes for putting them in the same file.
| dtech wrote:
| They are not the same at all. One practical reason is that in
| Kotlin (and other languages supporting this) you can always
| move the class to a dedicated file if it or the file becomes
| to unwieldy. With a nested class all the imports would need
| to change, which is a no go unless you can refactor all code
| using it in 1 go.
| beeboobaa wrote:
| This only matters if you are building a library intended to
| be consumed by other projects, and you are intending to
| release before deciding on a public API, and for some
| reason put multiple classes in a single file. Pretty
| specific case of a bad practice. Otherwise, just use your
| IDE's refactor capabilities.
| dvt wrote:
| This is a much larger discussion, and it's not as easy as adding
| headings, subheadings, etc. to your comments. There has been a
| clear cultural shift _against_ writing comments and properly
| documenting code. This is probably due to several factors,
| including unreasonable deadlines, bad architecture, job security,
| or meaningless output factors (e.g. lines of code).
|
| This is why open-source code tends to be some of the best
| architected and documented code out there: it's pretty much the
| definition of "by committee" (in the best sense of that term) and
| meant to be inviting to anyone to contribute. So _of course_ you
| want it to look nice.
|
| At BigCo, these factors don't really come into play (even though
| it would probably be better for the company if they did). There's
| also a lot of differences between writing software and building
| robots. Systems engineers build and refine requirements
| documents, pages upon pages of "this tiny part should be built
| like this, should have these constraints, etc." with
| traceability, discussion, and clear deliverables. Software, on
| the other hand, is unfortunately mostly just "patch a few things
| together and get the login form working."
| nightpool wrote:
| The overall advice here (add comments to your code to delineate
| different 'sections" of a file) is ultimately a bad hack to deal
| with the fact that your codebase is not structured well into
| function / modules / classes with a single responsibility and the
| right level of composition. Refactor your codebase to put the
| related code together, and then this "problem" will disappear and
| your code will be much easier to change in the future
| leghifla wrote:
| "Refactor your codebase to put the related code together"
|
| Of course it is a goal, but not always possible. You sometimes
| have two (or more) conflicting "relations" in the codebase.
| E.g.: you are dealing with taxes in various countries. Do you
| group by country or by kind of taxes (on sales, profits,
| earnings, energy, real estate...) ?
|
| The right answer really depends on how your team is organized
| and how you are making changes.
| froggit wrote:
| > E.g.: you are dealing with taxes in various countries. Do
| you group by country or by kind of taxes (on sales, profits,
| earnings, energy, real estate...) ?
|
| Seems like you would be dealing with one of 2 reasonably well
| defined problems in this case. How to group would follow
| logically. It's either:
|
| 1) "If i will be dealing with one specific type of tax at a
| time and how it is applied in different countries. (i.e. What
| are the sales taxes in UK, France, and Germany? )" Group by
| tax.
|
| OR
|
| 2) "If i will be looking at one country at a time and their
| assorted taxes. (i.e. What are the taxes in the UK for
| income, sales and value added?)" Group by country.
|
| Else "i have failed to properly define the problem." that's
| gonna be the problem.
| Bjartr wrote:
| How about when supporting both use cases? A multinational
| company might need the former for people making decisions
| across the whole company, and a country specific department
| doesn't need anything but what's relevant to that country.
|
| You could make two tools, but now you're duplicating
| implementation. Factor out a shared
| library/service/modularization-approach-de-jour? Good idea,
| but we're back to the question of how to structure things.
|
| You don't always get to enforce that "OR"
| jbenoit wrote:
| 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.
| chrismorgan wrote:
| 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.
| jaggederest wrote:
| > 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.
| jbenoit wrote:
| > 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!
| jaggederest wrote:
| 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.
| tgittos wrote:
| 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.
| norir wrote:
| > 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 wrote:
| 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.
| cellularmitosis wrote:
| Ah, yes, my favorite sort of HN reply. The author puts in a lot
| of effort to precisely articulate an issue which is difficult
| to articulate, and a commenter just dismisses the entire thing
| with a vague "You're holding it wrong".
| slingnow wrote:
| Sometimes, you really are just holding it wrong.
|
| Should the OP have written a manuscript to make you feel
| better? In your mind, should a long, drawn out article only
| be refuted by something of similar length?
| ziddoap wrote:
| > _Should the OP have written a manuscript to make you feel
| better? In your mind, should a long, drawn out article only
| be refuted by something of similar length?_
|
| It's not about "feeling better"? It's that the comment is
| very dismissive and sums up to "just refactor". Advice of
| "just refactor" (or "just do x") is lazy and ignores all
| context.
| Bjartr wrote:
| > Should the OP have written a manuscript to make you feel
| better?
|
| Nope
|
| > only be refuted by something of similar length?
|
| No, but if you don't address the points that have been
| made, you're not refuting. The comment says "refactor your
| codebase to put the related code together", but the article
| already addresses some downsides to this approach.
|
| Does the commenter believe that those downsides are more
| avoidable than the article states? Or maybe they believe
| the downsides are dwarfed by the upsides? Or maybe
| something else. We don't know, so we can't evaluate the
| position effectively.
| rustyminnow wrote:
| That would make me feel better. Without actionable advice,
| OP is just just grumbling. It's not helpful.
|
| > Refactor your codebase to put the related code together,
| and then this "problem" will disappear
|
| But how do I do that exactly? What does this even mean? I
| could literally put the whole codebase into one file since
| it is all related somehow or another.
| TeMPOraL wrote:
| > _Sometimes, you really are just holding it wrong._
|
| Yup. We all are. This is only a problem because editing raw
| plaintext code as single source of truth is a bad idea, and
| we're reaching its limits. "Split or don't split" is one of
| many holy wars that can't be solved, because they happen on
| the Pareto frontier. The only way to move forward is to
| accept that different coding tasks need different
| representations, and the computer should synthesize them
| for us, and we generally should _not_ touch the underlying
| single source of truth, anymore than we manually poke in
| assembly files generated by our compilers.
| PH95VuimJjqBqy wrote:
| People have been saying this forever. History has shown
| they were wrong then and history will eventually show
| that you're wrong too.
| cjaybo wrote:
| They should at least address the actual points raised by
| the article (which does already touch on the trade offs
| involved in doing what the commenter suggests, none of
| which were addressed by their comment). As it stands it
| sounds like they're responding to nothing more than the
| title of the post.
|
| It's a shallow criticism by HN standards.
| nightpool wrote:
| The author didn't put _any_ effort into actually trying to
| articulate a concrete example of a system that _was_ already
| well-architectured but _also_ needed section headers. All of
| the examples they brought up would be better-served by more
| sensible refactors that didn 't go to one extreme (4 line
| files) or the other (2000 line files). I'm sure there are
| rare files where having section header comments really is
| helpful, but personally I've never found it a useful way to
| organize my code, even in >500k LoC projects.
| tikhonj wrote:
| The problem is that real-world domains--or even just relatively
| complex software domains--do _not_ decompose perfectly into
| 100% self-contained units. It 's not even a limitation of any
| given programming language (although those limitations matter
| too!); we can't even have a purely conceptual ontology where
| everything neatly fits into exactly one slot in a neat
| hierarchy. That's just not how, well, _anything_ works.
|
| It's definitely worth trying to have your code neatly organized
| in a way that maps to some clean conceptual model, but doing
| that well is going to require using every tool at your disposal
| --which includes ways of grouping code that don't need the sort
| of crisp definition and conceptual coherence of an in-language
| abstraction.
|
| Sections and sub-sections seem like a reasonable way to do that
| with our modern, painfully limited tools. If we weren't limited
| by needing everything to live in plain text, I'd also reach for
| something like a system of tags.
| inChargeOfIT wrote:
| This is not always possible and a little short-sighted,
| especially when you are on a large, complex, established
| project with many contributors, where "just refactor 1.5
| million lines of code, spanning 1500 files that have evolved
| over a 10 year period" is just something not open for debate.
|
| In those cases, and in the cases where a single large file just
| makes more sense or is unavoidable (IaC/build scripts,
| shell/sql/migration scripts, config files, etc.), the author's
| methods are absolutely valuable.
| berlinquin wrote:
| Have been using a version of this recently: with C++ in Visual
| Studio you can add `#pragma region X` that will let you
| expand/collapse regions of code in the same file. Can be useful
| for top-level organization.
| smusamashah wrote:
| C# natively supports `#region <name>` and `#endregion`.
| IntelliJ supports the same using comments like `//#region
| <name>`.
| cglong wrote:
| TypeScript IDEs also typically support this via `// #region
| <name>` and `// #endregion`.
| earthboundkid wrote:
| Are y'all reading files top to bottom? This is weird to me. I
| pretty much just follow execution using jump to definition, and I
| rarely read something top to bottom in a way that having sections
| would be helpful.
| darth_avocado wrote:
| Haha, me too! I was concerned for a second. Though, I do
| organize my files bottom to top with the innermost part of the
| execution at the top.
| MuffinFlavored wrote:
| maybe it's a C thing where (without header definitions) you
| have to put main at bottom and anything it needs above it (same
| for functions that reference other functions/structs that
| aren't main) to make the compiler happy?
| gipp wrote:
| I honestly wish more people would try to organize their files
| to _be_ read top-to-bottom, it makes it much faster to grok
| something new.
|
| But of course there are lots of other factors constraining the
| way a file can/should be ordered, depending on language
| cellularmitosis wrote:
| Yes, the "inverted pyramid" concept from journalism. Most
| important details up top, implementation details down below.
|
| In our (Swift) codebase, this typically translates into
| "publicly-consumable interface up top, private and internal
| functions down below".
| okwubodu wrote:
| Within individual files I tend to create a mental index of
| names and purposes from top to bottom before tracing, which
| usually helps avoid redundant jumping or branching so deep it
| becomes difficult to keep track.
| dclowd9901 wrote:
| So thankful for Typescript/VSCode _chiefly_ for this reason.
| Doing this in JS before was hard, if not impossible. Now it's
| so much easier to follow control flow.
|
| That said, staying on topic with the article, I think the times
| where I have a difficult time following along are when it's
| just a monolithic function or class, and especially if it has
| implicit behaviors via decorators or mixins.
| jbenoit wrote:
| So do you never look at a program and try to figure out
| everything that it does? You always just read one function at a
| time?
| earthboundkid wrote:
| If I wanted a big picture, I would look at the docs to get
| the overview of the public interfaces. Once you're in the
| file, you're tracing execution for the most part.
| zogrodea wrote:
| The ML (metalanguage) family of languages like Standard ML, F#
| and OCaml intentionally enforce a one-way-flow where a function
| at the top cannot call anything below it (although there are
| ways to get around it).
|
| I like this approach to organisation because it helps avoid
| dependency cyles.
| https://fsharpforfunandprofit.com/posts/cyclic-dependencies/
|
| I once had to try and understand the entirety of a subsection
| by hopping between files that mutually depend on each other,
| which was quite confusing. UML diagrams I drew didn't help my
| understanding but drawing a dependency tree (the functions
| called that depends on no more are leaves and functions that
| call other functions are nodes) before I knew of this technique
| did help.
|
| This does have its disadvantages though so I think it's a good
| default in some cases but one should be given the choice to
| break it when needed.
| earthboundkid wrote:
| That makes the file backwards because main calls foo which
| calls bar, so it should be main, foo, bar; not bar, foo, main
| when you read it.
| mrkeen wrote:
| Where-clauses help break up long modules.
| somefunc = ... where subfunc1 = ...
| subfunc2 = ... otherfunc = ... where
| subfunc1 = ... where subfuncA = ...
| subfunc2 = ...
|
| Then the reader can instantly tell top-level concerns from
| implementation details, and the amount of jumping-around is
| reduced since those subfunctions are limited in scope.
| chrismorgan wrote:
| I've been playing around with using extra indentation for these
| sorts of purposes in the last couple of years, mostly at the sub-
| function level but also in the larger file situation described in
| the article. I've found it to work _so_ well that it has even
| been significantly influencing the design of the lightweight
| markup language I've been using for my own purposes for the last
| year or two and further designing as I go.
|
| The minor rough point is that text editors probably don't support
| mixing line folding techniques, so you probably won't be able to
| fold sections _and_ functions, which it would sometimes be nice
| to be able to do. Maybe at some point I'll get round to making a
| hybrid fold expression for Vim to mix multiple fold methods,
| though honestly I find Vim's folding pretty janky (my Rust
| foldexpr works fine when you load code, but start editing it and
| the fold tree rapidly falls apart in painful ways and it's
| absolutely Vim's fault) and would probably prefer to shift the
| entire thing to FFI for more flexibility.
|
| Some languages/IDE ecosystems support other ways of doing this
| sectioning, like Visual Studio's "regions", which gets around the
| folding problem since it's all in the language rather than being
| a mixture of language syntax and independently-chosen convention.
| marcrosoft wrote:
| In typed languages like go I don't need to look at module imports
| linked to files for navigating. With the vim shortcut 'gd' I can
| immediately jump to the definition making this entire discussion
| about where to put things almost irrelevant. I would still try to
| organize for reading.
| inChargeOfIT wrote:
| I find if you subscribe to the "Write libraries not software"
| mantra where your libraries/packages/classes are focused and
| adhere to the single responsibility principal, code organization
| kinda sorts itself out. But I agree with the author that
| organizing and commenting long files like this makes it easier to
| grok what's going on.
|
| But if you are clicking around a project and scrolling with your
| mouse, instead of taking advantage of your IDE's ability to use
| keystrokes to find and open files, jump to
| references/definitions, find and replace text, etc., you are
| handicapping yourself. It's worth the investment to learn.
| tikhonj wrote:
| I try to organize most of my code as libraries too, but I
| _still_ find having sections and subsections super useful. I
| sort of took that for granted because most of my code was in
| Haskell, and the Haskell documentation tool supports sections
| /subsections/etc natively, so I just used those to organize my
| larger modules.
| inChargeOfIT wrote:
| I totally agree. And some long/complex files are simply
| unavoidable (shell/build scripts, config files, etc).
| nucleardog wrote:
| > But if you are clicking around a project and scrolling with
| your mouse, instead of taking advantage of your IDE's ability
| to use keystrokes to find and open files, jump to
| references/definitions, find and replace text, etc., you are
| handicapping yourself. It's worth the investment to learn.
|
| Really? I've observed the opposite.
|
| The developers that I work with that make heavy use of things
| like fuzzy file matching, go to definition, etc tend to have a
| _much_ harder time understanding the codebase.
|
| My theory as to why this is the case is that they're never
| building or taking advantage of any higher level context.
| Having to browser through the directory structure (assuming it
| roughly mirrors the code structure), having to look through
| classes, etc forces you to actually build some awareness of the
| greater context of that method you're looking at.
|
| Using "go to definition", you may find yourself in a method,
| then later you hit "go to definition" and find yourself in
| another method, and unless you've made a conscious effort to
| observe so, you may very likely have never noticed they're even
| in the same class and presumably related.
|
| Using "go to definition" you might end up in a "process"
| method. Knowing that's in the "Image" class in the
| "ImageResizer" module would probably add a lot of clarity to
| what that's doing before you even get started looking at code.
|
| When I need to onboard in a new codebase, I very much _don't_
| use those tools until I have a solid grasp on the big picture.
| radiator wrote:
| Yes. I would have liked to add something more, but you have
| said everything there is to say about this subject.
| PH95VuimJjqBqy wrote:
| I just can't imagine there's any real correlation between a
| developers ability and their use of specific IDE features.
| polyrand wrote:
| I kind of agree with the post. For me, this technique almost
| starts overlapping with literate programming[0].
|
| One trick I use[1] is adding certain characters before the
| section name. e.g: !! settings
|
| This makes searching and jumping between sections a lot easier.
|
| [0]: https://en.wikipedia.org/wiki/Literate_programming
|
| [1]: https://ricardoanderegg.com/posts/write-apps-in-single-file/
| tikhonj wrote:
| The Emacs version of this is using ^L (the ASCII form feed
| character), which lets you jump around using Emacs's built in
| page navigation commands.
|
| I've used this occasionally in Emacs Lisp code and it's pretty
| nice, but I've never done it in other languages because I
| suspect that non-Emacs-users won't be able to handle it :P
|
| The Emacs Wiki has a whole page on this:
| https://www.emacswiki.org/emacs/PageBreaks
| emmanueloga_ wrote:
| Things humans are bad at: organizing files, topological sorting,
| ontologies.
|
| Things computers are good at: organizing files, topological
| sorting, ontologies.
|
| The point is I wish we could just ask the computer to sort things
| out for us, show different views, etc. this would require a
| software system able to work with more granular code units, maybe
| something like [1].
|
| I still have some ptsd from huge refactoring where a big part of
| the hassle was to manually create directories, move files around,
| fix imports, build files, cyclic dependency errors, sigh...
|
| I suspect a good solution would be to have a language agnostic
| dsl to describe a program's data flow, then use it to generate
| the boilerplate of functions involved. Then you could ask the
| system to show you only the pieces of the code strictly related
| to a certain feature, hopefully never again have to deal with
| file structure manually.
|
| 1: https://www.unison-lang.org/
| MetaWhirledPeas wrote:
| > The point is I wish we could just ask the computer to sort
| things out for us, show different views, etc.
|
| I agree. I'm usually opinionated about a related subject: code
| formatting. But I'm not too opinionated in one case, where
| we're using _Prettier_. The project is autoformatted and
| expects everyone else to do the same. It 's so refreshing to
| let the computer take over sometimes, even if the end result
| isn't exactly what I would have typed out myself. If a piece of
| software could so something similar with the folders, files,
| and code that would be pretty great. Maybe. It seems like a
| much harder problem to solve than simple formatting, without
| introducing a bunch of bugs.
|
| But you seem to be suggesting a different way of _viewing_ the
| code, which I guess might be the way. But still underneath you
| 'd have the spaghetti code, just sitting there not being dealt
| with, like a complicated Microsoft Word document.
| norman784 wrote:
| I was about to comment also that unison is an interesting
| approach, we need more tooling support before it can be
| possible, ideally there need to be a protocol that the new kind
| of editors can be built on top, similar to how LSP enabled
| editors to support different programming languages without a
| proprietary implementation.
|
| I'm wondering if the unison devs already have plans on working
| on a protocol like that.
| jerf wrote:
| "The point is I wish we could just ask the computer to sort
| things out for us, show different views, etc. this would
| require a software system able to work with more granular code
| units, maybe something like [1]."
|
| The problem I've seen with this idea is that in order for it to
| work, you have to be willing to add more metadata to your
| program, because programs themselves don't have the necessary
| data in them. You can make it mandatory to your language, but
| than just raises the friction for people trying to use that
| language.
|
| But, if you're willing to add the metadata to a hypothetical
| new system for slicing and dicing code, why aren't you using
| the existing mechanisms in your system for organizing and
| documenting things?
|
| If you are, then you make the delta between "it may not be
| perfect but here's some documented and organized code" and the
| perfect vision small enough to not be worth a lot of effort to
| chase.
|
| If you aren't, then you aren't going to give the perfect all-
| singing slicer and dicer what it needs either.
|
| Replace "you" with "coworker(s)" for the same dilemma, only
| sadder. And your generic strawman coworkers are going to be
| very upset when you try to get them to use this language...
| "it's so hard, it's always complaining about perfectly good
| code, I'm missing my deadlines because it's making me document
| things I'll never use, I'm just putting 'a' as the
| documentation for these things anyhow, oh look here's our boss
| ordering us to go back to our previous language because we're
| all spending too much time documenting rather than building new
| features".
|
| Some things can't really be fixed by process.
| solarkraft wrote:
| > order for it to work, you have to be willing to add more
| metadata to your program, because programs themselves don't
| have the necessary data in them
|
| I'm kind of stumped by this assertion. What data is missing?
|
| If it is required or necessary, doesn't it make it just data,
| as in an integral part of the code?
| trealira wrote:
| > The problem I've seen with this idea is that in order for
| it to work, you have to be willing to add more metadata to
| your program, because programs themselves don't have the
| necessary data in them. You can make it mandatory to your
| language, but than just raises the friction for people trying
| to use that language.
|
| I'm confused by what you mean. Can you be more specific as to
| what sort of metadata that has to be embedded in the code
| would be needed?
|
| I've never used it, but watching this Smalltalk-80 IDE
| demonstration seems like it could be a workable idea.
|
| https://youtu.be/JLPiMl8XUKU?si=Hly_8m4GiaDSQmpn&t=269
| crabbone wrote:
| > Things humans are bad at: organizing files
|
| Based on what do you make this statement?
|
| I don't feel like this is a problem. At least not for me :| Of
| course, size can make everything a problem, but for whatever
| projects I had to work with, organizing files was usually an
| entry-level problem that would normally sort itself out after a
| month or so.
|
| In other words, I don't feel like this is a problem worth
| solving.
| solarkraft wrote:
| I do believe that text in files isn't the ideal way of
| expressing and structuring program instructions.
|
| But the friction to get something else established is so huge -
| all tooling would need to change ... unless perhaps one
| develops a way to translate between the internal format and
| text.
| hoten wrote:
| Here's a good rule to use, only applies in the extreme.
|
| When your cpp file is so large that you begin losing debug info
| in upstream tools like Sentry, you should probably split it.
|
| Related, when your functions are so large that they fail to
| compile under higher debug modes for emscripten (too many
| locals!), you should probably split it.
|
| (send help)
| wruza wrote:
| Was doing that for ages. I have snippets com and com2 for first
| and second level full-width headers. Third level is just a
| comment surrounded by empty or "//" lines.
|
| ";" cycles through headers.
|
| Never understood that "more import lines than lines of code"
| style too.
| amadeuspagel wrote:
| Maybe plaintext is not the perfect way to organize code.
| jameshart wrote:
| Underappreciated aspects of the C# compilation model:
|
| 1: file agnostic. While files provide a scope for imports, in
| general the compiler can't tell the difference between the same
| set of classes split across multiple files or crammed into the
| same file.
|
| 2: unordered - files don't import one another, or get processed
| in particular sequence. The compiler takes a _set_ of files and
| turns that into a _set_ of type definitions.
|
| 2: partial types, which lets you even split a class definition
| between multiple files
|
| 3: regions, to let you bracket of sections within a file and
| organize things how you want.
|
| No 'one class per file' rules. No 'references at the top of the
| file to every other file you need'. You can reorganize code
| freely, adding or combining files at will.
| bbkane wrote:
| I think, by using a directory as "the module unit", Go gets
| similar benefits while being simpler.
| aragonite wrote:
| That sounds like something I really wish were available for JS
| development.
|
| Used to have a setup where, during development, I write all my
| .js files as "script files" rather than modules, all placed
| inside a folder, and the "build-step" is simply concatenating
| all .js files in that folder. All the functions in each script
| file are globally visible from all the other script files and
| there's no need to import/export anything. No one should
| _publish_ code in that form, but during _development_ it was
| incredibly freeing and helps me concentrate on the actual
| programming tasks at hand rather than getting sidetracked by
| trying to figure out the right way to organize the code into
| modules, something that (imo) I 'm in a much better position to
| do when the programming tasks have largely been solved.
|
| It's like writing a book. The natural process is to first
| create substantive content in fragments and then gradually for
| a chapter or section structure to naturally emerge from these
| fragmentary bits of content. Focusing too much on 'modules'
| during early development is imo akin to being preoccupied with
| spending time deciding what chapters and sections you want your
| book to have before even having a substantial base of content.
|
| Unfortunately the current tooling for JS doesn't really support
| this workflow as well as I'd like.
| kraftman wrote:
| This is kind of related, but I've always wondered what a 2D or 3D
| IDE would look like, if we could drop the limitations of files
| and working top to bottom, and instead be able to group code more
| spatially (and i guess still have it then outpt to files for
| storage.) Does anything like this that isnt a GUI drag and drop
| editor?
| bbkane wrote:
| https://www.unison-lang.org/ stores code in SQLite (last I
| checked) and looks super interesting.
|
| In a related idea, I wonder what organizing code imports by one
| or more "tags" instead of import paths would be like. Probably
| too confusing after a while (tag systems tend to get that way),
| but fun to daydream about
| marwis wrote:
| JetBrains got you covered: https://www.jetbrains.com/mps/
| swizzler wrote:
| There is code bubbles. Early demo:
| https://www.youtube.com/watch?v=PsPX0nElJ0k current site
| (eclipse plugin for java projects?):
| https://cs.brown.edu/~spr/codebubbles/index.html. Maybe also
| inspired Visual Studio debugger exploration. I haven't used it
| (but have wanted to)
| kraftman wrote:
| This is exactly what I meant, thanks!
| SnooSux wrote:
| I like tools like vim and tmux for being able to quickly and
| easily split windows and show multiple terminals. If I could
| extend things out further than just my monitor that would be
| really cool. Or stack windows on top of each other so I could
| scroll through windows in a specific spot.
| mattxxx wrote:
| Hm this is a good idea. Or similarly, be able to make a "meta
| file" that maybe contains every function that was used in a
| chain... Cool thought
| vemv wrote:
| In practice, the chances that N programmers with follow the
| pretty comment convention of a given file approach zero, as time
| passes.
|
| Splitting into files is an approach that is easier to lint
| against (e.g. max 500 lines - a best-effort mechanism to foster
| SRP).
|
| And it's not really problematic after mastering a few key
| aspects: jump to definition, and more interestingly Peek
| Definition.
|
| It's also important to not traverse files top-to-bottom (which
| yes, is very tempting).
|
| Optimal code traversal is tree-like, you jump from definition to
| definition, skipping over the irrelevant, and gathering necessary
| info _on demand_.
|
| The file/line location of a function becomes irrelevant.
| solarkraft wrote:
| > It's also important to not traverse files top-to-bottom
| (which yes, is very tempting). Optimal code traversal is tree-
| like, you jump from definition to definition, skipping over the
| irrelevant, and gathering necessary info on demand.
|
| A (successful!) ex-colleague of mine read thousands of lines
| long files top to bottom.
|
| I don't know how, but somehow this worked for them.
| ilrwbwrkhv wrote:
| The rails world is filled with stuff like this:
|
| class Something
|
| def execute first_method
|
| end
|
| private
|
| def first_method second_method + 1
|
| end
|
| def second_method 2
|
| end
|
| end
|
| This should have been just one method instead of thousands of
| tiny one line methods. I blame Uncle Bob and that whole group for
| brainwashing the Ruby community.
___________________________________________________________________
(page generated 2023-12-01 23:01 UTC)