
Ask HN: Better code readability/reviewability - eyer2016
I&#x27;m in a situation where several nested functions are used and each of these functions are present in different files (which are in different directories). (I&#x27;m sure there&#x27;s legitimate reason for modularizing code to such an extent).<p>I&#x27;m having trouble reading the code and being able to understand what exactly is happening.<p>Is there a tool that would comment function calls and replace them with the function body instead so that I can read it better? Also, would it be able to do this on-demand.<p>For e.g., in ST3, I could call a function that would find the definition of the function in my project and replace it in my file and <i>does not</i> do so for calls made in the replaced function body until I ask it to?<p>In my context, this is about Javascript, but this is a language-agnostic question.<p>Alternate question: How the heck do you deal with situations like this?
======
Someone
You're looking for a refactoring tool that can perform 'inline method'
refactorings (the reverse of 'extract method', which turns whatever you
selected into a function call)

And yes, the idea is language-agnostic, but tools doing it aren't, and,
generally, tools are easier to write for less dynamic languages.

One way to deal with code you do not understand is to print out the various
functions, sit down with them away from your computer, but with a few
differently colored pens or pencils, and start making notes.

It also can help if you can single-step through the code with a debugger, even
if it's just to be able to write down a few (inputs, return value) pairs.

------
dozzie
> I'm having trouble reading the code and being able to understand what
> exactly is happening.

[...]

> Alternate question: How the heck do you deal with situations like this?

Rewrite the fragment so it's easier to understand. Because...

> [E]ach of [several nested] functions are present in different files (which
> are in different directories). (I'm sure there's legitimate reason for
> modularizing code to such an extent).

...you probably have code that works with several different abstraction levels
at the same time.

And no, there may be no legitimate reason to keep it that much split up (as
you call, "modular"). It may be just an abuse of overestimated DRY principle.

------
happycodework
Code connect maybe, best bet is to single step through the whole thing a few
times.

