3 ms·

The 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. F

The 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.

karmakaze 2y ago
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).
jasode 2y ago
>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.
carlinm 2y ago
I don’t see this as hiding code complexity or an alternative to writing cleaner code. It seems the argument is that when we come to a file/class/etc., that we should be initially presented with the outline rather than both the outline and details. It’s an approach to orienting oneself to a grouping of functionality, made first class by the IDE. It’s almost like opening a book and starting with the table of contents before diving into any specific chapter’s details. Allowing the reader to get a sense of what’s covered by this grouping of functionality before diving into the details. I haven’t tried this approach myself but it seems like an interesting exercise at the least.

karmakaze 2y ago

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).

jasode 2y ago

>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.

carlinm 2y ago

I don’t see this as hiding code complexity or an alternative to writing cleaner code. It seems the argument is that when we come to a file/class/etc., that we should be initially presented with the outline rather than both the outline and details. It’s an approach to orienting oneself to a grouping of functionality, made first class by the IDE. It’s almost like opening a book and starting with the table of contents before diving into any specific chapter’s details. Allowing the reader to get a sense of what’s covered by this grouping of functionality before diving into the details. I haven’t tried this approach myself but it seems like an interesting exercise at the least.