[HN Gopher] Codegraph - static code analyzator / code diagramer
       ___________________________________________________________________
        
       Codegraph - static code analyzator / code diagramer
        
       Author : sargstuff
       Score  : 68 points
       Date   : 2023-04-17 17:02 UTC (5 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | marcodiego wrote:
       | Unrelated, but curious: when "analyzator" should be used instead
       | of "analyzer"?
        
         | chrisweekly wrote:
         | Never. "Analyzator" is not a word.
         | 
         | The HN title matches the repo's README, which was authored by
         | someone whose English language skills are questionable.
        
       | xnuinside wrote:
       | I was really surprised to saw a lot of stars on one of my oldest
       | repos )) it was just for my purposes and I didn't continue work
       | on it because thought that it is not needed at all ))
        
       | esafak wrote:
       | That graph is illegible. I would remove most of the labels by
       | default and show them on hover.
        
         | UncleMeat wrote:
         | Even doing that won't help.
         | 
         | Like, a reasonably complex program is going to have a call
         | graph with tens or even hundreds of thousands of nodes.
         | Graphviz won't save you. Collapsing sccs won't save you. It
         | won't actually be useful to navigate.
        
           | esafak wrote:
           | They could collapse nodes into clusters, and reveal them on
           | zoom, etc.
           | 
           | This needs more sophistication to be useful is what I'm
           | saying.
        
         | prettyStandard wrote:
         | Agree but maybe only show labels for the largest modules and
         | functions and also scale node size relative to function and
         | module size.
        
       | jschrf wrote:
       | Nice work!
       | 
       | Other posts in this thread are touching on it, but graph layout
       | and layer segmentations are where you could improve.
       | 
       | Screen real-estate is the biggest challenge when visualizing
       | large amounts of code.
       | 
       | Similar to maps show different detail levels based on aspect
       | ratio and zoom, you can decompose your "features" (mapping
       | terminology) based on level, i.e.
       | packages->modules->functions->code
       | 
       | OP, have you ever used Gephi? I used to build static analysis
       | tools for viz of large-scale codebases. Taking a bit of time to
       | export analysis data into a Gephi format (GEXF in my case) really
       | helped.
       | 
       | In Gephi, you can play around with different layout algorithms
       | (peep the plugins). This may help you select a layout algo or
       | combination thereof to help render tons of data in a human-
       | friendly form.
        
       | theK wrote:
       | Python only?
       | 
       | Cool tool nonetheless, have built similar things to visualize
       | code architecture and create doc artifacts in CI, usually the
       | biggest challenge is to scope the pieces that will be included
       | and what layout algo to use, maybe a feature to implement?
        
       | adamc wrote:
       | I haven't looked very hard, but `pip install codegraph` didn't
       | result in a codegraph command anywhere. (This was macos, using a
       | Python 3.8 venv.)
       | 
       | Digging around a bit found a 'cg' command, which seems to be
       | codegraph (based on the --help output). Didn't show anything
       | interesting for a Django app, though... I'm guessing it couldn't
       | really follow what manage.py was doing?
       | 
       | Anyhow, if 'cg' is the command, might want to update the docs.
        
         | sargstuff wrote:
         | README for codequery[0]outlines an overview of tool set to go
         | from source code to visualization. (although, not as a generate
         | live updates per editor changes)
         | 
         | [0] : https://github.com/ruben2020/codequery
        
       | MoreQARespect wrote:
       | [dead]
        
       | sasas wrote:
       | Can anyone recommend something similar for Java / Smali ?
       | Specific use case is reverse engineering Android application with
       | partially obsufcated code.
       | 
       | Current approach is following "xrefs" in JADX and hooking methods
       | with dynamic instrumentation with Frida (displaying backtraces
       | etc). Got to be a quicker way while chipping away renaming
       | classes and methods and mapping out source/sinks.
        
       | cmcconomy wrote:
       | Although it's discontinued, SourceTrail is still great for this
       | purpose.
        
       | Nezteb wrote:
       | Shortly before this was posted, I asked for a similar thing!
       | https://news.ycombinator.com/item?id=35603022
       | 
       | Although in my case it'd ideally be language-agnostic and hook
       | into LSP so that I can click on nodes and jump to various
       | files/modules/functions.
       | 
       | Still a cool project though!
        
         | kevin_thibedeau wrote:
         | Radare2
         | 
         | https://www.radare.org/r/
        
         | sargstuff wrote:
         | emacs. LSP (under editor such as emacs[0]) provides the
         | context/way for being able to define a specific language parse
         | specifics about where to add/define emacs hooks/jump points for
         | a given language nodes/files/modules/functions)
         | 
         | [0] : https://www.masteringemacs.org/article/tree-sitter-
         | complicat...
        
       | anigbrowl wrote:
       | Good concept. visualization is poor. Force Atlas is really not
       | that great for structural analysis, and nodes need to be weighted
       | by degree among other more code-specific factors. Consider
       | bringing the code graph into NetworkX or some similar library and
       | using graphML to leverage existing visualization solutions rather
       | than reinventing the wheel.
        
       ___________________________________________________________________
       (page generated 2023-04-17 23:00 UTC)