This is exactly how aider shares code context with LLMs using a “repo map”. It uses tree sitter to collapse relevant files into this sort of folded version, showing function signatures but eliding their bodies.
A Missing IDE Feature
11–20 of 54 posts
Re: A Missing IDE Feature
#12https://github.com/zenozeng/yafolding.el
has been around for at least a decade -- and that is basically helper code on top of functionality that's been available for longer than a fair few people reading this have been alive.
Re: A Missing IDE Feature
#13I'd expect short, important method bodies that should be visible by default to vastly outnumber long and uninteresting method bodies that should be folded away by default.
This is, of course, my experience with mostly unexciting Java and Python; there should be options, maybe per language or per project, or even heuristics (e.g. fold long methods, by character count and/or line count, and recognized getters and setters but not other short methods).
Re: A Missing IDE Feature
#14I was recently using IntelliJ to write some HTML. I suddenly noticed a wayward & character. It was blue so I assumed that was syntax highlighted... I quickly changed that to a valid entity and committed without really reviewing the code (i know I'm an idiot).
Turns out that JetBrains format the entity as the resulting character... a feature that was meant to make code readable had confused me. I had similar issues with clion which presents weird notations on the code with no indication of their purpose. This is a double edged sword.
Re: A Missing IDE Feature
#15IMO this depends on the reading style.
"Fold Method Bodies by Default" is something I deactivate immediately. After two decades of reading code, I am optimized to read syntax-highlighted code pretty hard. This just hides the stuff I am looking for - I read code because I want to know what it does.
For an overview I look at the outline. With wide screens, I think it is a much better place for a structural overview. I would be more happy to see advancements there.
Re: A Missing IDE Feature
#16https://github.com/zenozeng/yafolding.el has been around for at least a decade -- and that is basically helper code on top of functionality that's been available for longer than a fair few people reading this have been alive.
From the linked post:
> First, only method bodies are folded. This is a syntactic check — we are not folding the second level.
Re: A Missing IDE Feature
#17Controlled by foldexpr in Neo/Vim IIRC, and I think VS proper has a shortcut Ctrl+M,Ctrl+O from memory. To round it out, VS Code has Ctrl+K+,Ctrl+2 where 2 is your level of folding of choice. Despite using these 3 editors every day and knowing the folding shortcut, I still don't collapse bodies as a matter of routine and I think I'd find it annoying if I had to toggle each open just to find relevant code.
There's also something to be said for the idea that code has a 2D shape to it and recognising parts visually can make navigating it a little easier if you're bouncing between a couple of areas for a particular change. I wouldn't want to obscure that, not by default anyway. But to each their own!
Re: A Missing IDE Feature
#18The IDE isn't the root cause though, hiding code complexity is a patch. Write cleaner code or use a higher level language that allows for more readable code. For example, some Go developers (...mainly Rob Pike, granted) eschew even syntax highlighting, as readable code shouldn't need colors to make sense of it.
I would prefer smaller method bodies be written in the first place. Not always though--it depends, but it's up to the author first.
Tools can help but isn't the cure-all. I would prefer gradual folding (e.g. fold levels 4+ or fold/unfold one level).
Re: A Missing IDE Feature
#19The IDE isn't the root cause though, hiding code complexity is a patch. Write cleaner code or use a higher level language that allows for more readable code. For example, some Go developers (...mainly Rob Pike, granted) eschew even syntax highlighting, as readable code shouldn't need colors to make sense of it.
>The IDE isn't the root cause though, hiding code complexity is a patch.
Write cleaner code
To clarify, the context of this article is using tools to understand someone else's code. (The author's setting: ">Suppose you are casually reading the source code of rust-analyzer, and are curious about handling of method bodies. There’s a Body struct in the code base, and you want to understand how it is used.")
In that particular perspective, the IDE is the root cause because it can be purposely designed to highlight/emphasize/annotate/correlate/hide ... various aspects of the unfamiliar codebase.
If the author then later chooses to refactor the code, that's when your advice of "write cleaner code" would apply.
Re: A Missing IDE Feature
#20I am a grownup and therefore have no problem with "fold methods by default" being a toggle-able option, but this argument seemed odd to me:
> I think it is pretty obvious how awesome this actually is. Code is read more often than written, and this is one of the best multipliers for readability. Most of the code is in method bodies, but most important code is in function signatures. Folding bodies auto-magically hide the 80% of boring code, leaving the most important 20%.
I see where they're coming from, especially for codebases you already understand. But my workflow for new codebases is to at least visually inspect the method implementation before deciding whether or not to hide it. Does it actually look like boilerplate? Does it invoke any functions I haven't seen before? If it seems nontrivial, read it! Does the computation basically match my English-language description of the signature, or is there something deeper I missed? If everything was hidden by default I would either waste time un-hiding everything, or make lazy mistakes by saying "eh I'm pretty sure that's boilerplate." Coding by gluing together function signatures without reading the implementation is a recipe for making business-logic bugs.
My problem is similar to why I don't like using LLMs: taking the 80-20 thing at face value, you don't know which 20% of methods have nontrivial internal semantics which aren't conveyed by the type system, unless you already have a solid understanding of the code. (Note that Rust's type system does actually evade mutability / concurrency issues. But not incorrect business logic: it is not yet Lean or Idris.) I just don't like rolling the dice on this stuff - business logic bugs are horrible! They are difficult to suss out, especially if you weren't fully diligent in understanding the logic in the first place. Why would you roll a d5 on that?
Part of my aversion is that I am lucky enough to not be in a hurry. At my last job - 70 hrs/week of R and Python, reading papers, and writing emails - I would have been much more tempted for these "multipliers for readability," especially ChatGPT. But when you're not in a hurry, you are more sensitive to these multipliers also multiplying laziness and misconceptions.