code-dive   30

Call graph - Wikipedia
I've found both static and dynamic versions useful (former mostly when I don't want to go thru pain of compiling something)

best options AFAICT:

C/C++ and maybe Go:


both static and dynamic in one tool

both static and dynamic in one tool

more up-to-date forks: and
old docs:



I believe all the dynamic tools listed here support weighting nodes and edges by CPU time/samples (inclusive and exclusive of descendants) and discrete calls. In the case of the gperftools and the Java option you probably have to parse the output to get the latter, tho.

IIRC Dtrace has probes for function entry/exit. So that's an option as well.
concept  wiki  reference  tools  devtools  graphs  trees  programming  code-dive  let-me-see  big-picture  libraries  software  recommendations  list  top-n  links  c(pp)  golang  python  javascript  jvm  stackex  q-n-a  howto  yak-shaving  visualization  dataviz  performance  structure  oss  osx  unix  linux  static-dynamic 
4 weeks ago by nhaliday
Cleaner, more elegant, and harder to recognize | The Old New Thing
Really easy
Writing bad error-code-based code
Writing bad exception-based code

Writing good error-code-based code

Really hard
Writing good exception-based code


Really easy
Recognizing that error-code-based code is badly-written
Recognizing the difference between bad error-code-based code and
not-bad error-code-based code.

Recognizing that error-code-base code is not badly-written

Really hard
Recognizing that exception-based code is badly-written
Recognizing that exception-based code is not badly-written
Recognizing the difference between bad exception-based code
and not-bad exception-based code
techtariat  org:com  microsoft  working-stiff  pragmatic  carmack  error  error-handling  programming  rhetoric  debate  critique  pls  search  structure  cost-benefit  comparison  summary  intricacy  certificates-recognition  commentary  multi  contrarianism  correctness  quality  code-dive  cracker-prog 
7 weeks ago by nhaliday
Frama-C is organized with a plug-in architecture (comparable to that of the Gimp or Eclipse). A common kernel centralizes information and conducts the analysis. Plug-ins interact with each other through interfaces defined by the kernel. This makes for robustness in the development of Frama-C while allowing a wide functionality spectrum.


Three heavyweight plug-ins that are used by the other plug-ins:

- Eva (Evolved Value analysis)
This plug-in computes variation domains for variables. It is quite automatic, although the user may guide the analysis in places. It handles a wide spectrum of C constructs. This plug-in uses abstract interpretation techniques.
- Jessie and Wp, two deductive verification plug-ins
These plug-ins are based on weakest precondition computation techniques. They allow to prove that C functions satisfy their specification as expressed in ACSL. These proofs are modular: the specifications of the called functions are used to establish the proof without looking at their code.

For browsing unfamiliar code:
- Impact analysis
This plug-in highlights the locations in the source code that are impacted by a modification.
- Scope & Data-flow browsing
This plug-in allows the user to navigate the dataflow of the program, from definition to use or from use to definition.
- Variable occurrence browsing
Also provided as a simple example for new plug-in development, this plug-in allows the user to reach the statements where a given variable is used.
- Metrics calculation
This plug-in allows the user to compute various metrics from the source code.

For code transformation:
- Semantic constant folding
This plug-in makes use of the results of the evolved value analysis plug-in to replace, in the source code, the constant expressions by their values. Because it relies on EVA, it is able to do more of these simplifications than a syntactic analysis would.
- Slicing
This plug-in slices the code according to a user-provided criterion: it creates a copy of the program, but keeps only those parts which are necessary with respect to the given criterion.
- Spare code: remove "spare code", code that does not contribute to the final results of the program.
- E-ACSL: translate annotations into C code for runtime assertion checking.
For verifying functional specifications:

- Aoraï: verify specifications expressed as LTL (Linear Temporal Logic) formulas
Other functionalities documented together with the EVA plug-in can be considered as verifying low-level functional specifications (inputs, outputs, dependencies,…)
For test-case generation:

- PathCrawler automatically finds test-case inputs to ensure coverage of a C function. It can be used for structural unit testing, as a complement to static analysis or to study the feasible execution paths of the function.
For concurrent programs:

- Mthread
This plug-in automatically analyzes concurrent C programs, using the EVA plug-in, taking into account all possible thread interactions. At the end of its execution, the concurrent behavior of each thread is over-approximated, resulting in precise information about shared variables, which mutex protects a part of the code, etc.
Front-end for other languages

- Frama-Clang
This plug-in provides a C++ front-end to Frama-C, based on the clang compiler. It transforms C++ code into a Frama-C AST, which can then be analyzed by the plug-ins above. Note however that it is very experimental and only supports a subset of C++11
tools  devtools  formal-methods  programming  software  c(pp)  systems  memory-management  ocaml-sml  debugging  checking  rigor  oss  code-dive  graphs  state  metrics  llvm  gallic  cool  worrydream  impact  flux-stasis  correctness  computer-memory  structure  static-dynamic 
12 weeks ago by nhaliday
architecture - What is the most effective way to add functionality to unfamiliar, structurally unsound code? - Software Engineering Stack Exchange
If the required changes are small then follow the original coding style, that way someone picking up the code after you only needs to get used to one set idiosyncrasies.

If the required changes are large and the changes are concentrated in a few functions or modules, then, take the opportunity to refactor these modules and clean up the code.

Above all do not re-factor working code which has nothing to do with the immediate change request. It takes too much time, it introduces bugs, and, you may inadvertently stamp on a business rule that has taken years to perfect. Your boss will hate you for being so slow to deliver small changes, and, your users will hate you for crashing a system that ran for years without problems.


Rule 1: the better skilled are the developers who wrote the code, the more refactoring vs. rewriting from scratch you must use.

Rule 2: the larger is the project, the more refactoring vs. rewriting from scratch you must use.
q-n-a  stackex  programming  engineering  best-practices  flux-stasis  retrofit  code-dive  working-stiff  advice  code-organizing 
may 2019 by nhaliday

related tags

abstraction  advice  analogy  analysis  aphorism  backup  benchmarks  best-practices  big-picture  books  browser  c(pp)  carmack  certificates-recognition  checking  checklists  cocoa  code-organizing  commentary  comparison  compilers  composition-decomposition  computer-memory  concept  contrarianism  cool  correctness  cost-benefit  cracker-prog  critique  data-structures  dataviz  dbs  debate  debt  debugging  deep-learning  design  devtools  discussion  documentation  engineering  error-handling  error  expert-experience  explanation  exposition  facebook  flexibility  flux-stasis  formal-methods  frontend  functional  gallic  git  golang  google  gradient-descent  graphs  guide  hn  howto  ide  impact  info-foraging  init  interview-prep  intricacy  ios  javascript  jvm  let-me-see  libraries  linear-algebra  links  linux  list  llvm  machine-learning  memory-management  metrics  microsoft  multi  nitty-gritty  ocaml-sml  oop  org:com  org:med  oss  osx  performance  pls  plt  pragmatic  presentation  problem-solving  programming  project  python  q-n-a  qra  quality  recommendations  reference  reflection  repo  retrofit  review  rhetoric  rigidity  rigor  scala  scaling-tech  sci-comp  search  sequential  shipping  slides  software  stackex  startups  state  static-dynamic  structure  summary  system-design  systems  tech  techtariat  terminal  thinking  time  tools  top-n  tradeoffs  trees  tutorial  types  unix  vcs  video  visualization  web  wiki  workflow  working-stiff  worrydream  yak-shaving  🖥 

Copy this bookmark: