nhaliday + code-dive   36

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: https://github.com/gperftools/gperftools

static: https://github.com/Vermeille/clang-callgraph

Go: https://stackoverflow.com/questions/31362332/creating-call-graph-in-golang
both static and dynamic in one tool

Java: https://github.com/gousiosg/java-callgraph
both static and dynamic in one tool

more up-to-date forks: https://github.com/daneads/pycallgraph2 and https://github.com/YannLuo/pycallgraph
old docs: https://pycallgraph.readthedocs.io/en/master/

static: https://github.com/davidfraser/pyan

various: https://github.com/jrfonseca/gprof2dot

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 
7 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 
10 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 
may 2019 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
its-not-software - steveyegge2
You don't work in the software industry.


So what's the software industry, and how do we differ from it?

Well, the software industry is what you learn about in school, and it's what you probably did at your previous company. The software industry produces software that runs on customers' machines — that is, software intended to run on a machine over which you have no control.

So it includes pretty much everything that Microsoft does: Windows and every application you download for it, including your browser.

It also includes everything that runs in the browser, including Flash applications, Java applets, and plug-ins like Adobe's Acrobat Reader. Their deployment model is a little different from the "classic" deployment models, but it's still software that you package up and release to some unknown client box.



Our industry is so different from the software industry, and it's so important to draw a clear distinction, that it needs a new name. I'll call it Servware for now, lacking anything better. Hardware, firmware, software, servware. It fits well enough.

Servware is stuff that lives on your own servers. I call it "stuff" advisedly, since it's more than just software; it includes configuration, monitoring systems, data, documentation, and everything else you've got there, all acting in concert to produce some observable user experience on the other side of a network connection.
techtariat  sv  tech  rhetoric  essay  software  saas  devops  engineering  programming  contrarianism  list  top-n  best-practices  applicability-prereqs  desktop  flux-stasis  homo-hetero  trends  games  thinking  checklists  dbs  models  communication  tutorial  wiki  integration-extension  frameworks  api  whole-partial-many  metrics  retrofit  c(pp)  pls  code-dive  planning  working-stiff  composition-decomposition  libraries  conceptual-vocab  amazon  system-design  cracker-prog  tech-infrastructure  blowhards 
may 2019 by nhaliday
Book review: "Working Effectively with Legacy Code" by Michael C. Feathers - Eli Bendersky's website
The basic premise of the book is simple, and can be summarized as follows:

To improve some piece of code, we must be able to refactor it.
To be able to refactor code, we must have tests that prove our refactoring didn't break anything.
To have reasonable tests, the code has to be testable; that is, it should be in a form amenable to test harnessing. This most often means breaking implicit dependencies.
... and the author spends about 400 pages on how to achieve that. This book is dense, and it took me a long time to plow through it. I started reading linerarly, but very soon discovered this approach doesn't work. So I began hopping forward and backward between the main text and the "dependency-breaking techniques" chapter which holds isolated recipes for dealing with specific kinds of dependencies. There's quite a bit of repetition in the book, which makes it even more tedious to read.

The techniques described by the author are as terrible as the code they're up against. Horrible abuses of the preprocessor in C/C++, abuses of inheritance in C++ and Java, and so on. Particularly the latter is quite sobering. If you love OOP beware - this book may leave you disenchanted, if not full of hate.

To reiterate the conclusion I already presented earlier - get this book if you have to work with old balls of mud; it will be effort well spent. Otherwise, if you're working on one of those new-age continuously integrated codebases with a 2/1 test to code ratio, feel free to skip it.
techtariat  books  review  summary  critique  engineering  programming  intricacy  code-dive  best-practices  checklists  checking  working-stiff  retrofit  oop  code-organizing 
july 2017 by nhaliday

bundles : techie

related tags

abstraction  accretion  acm  advanced  advice  age-generation  aggregator  aging  algorithmic-econ  algorithms  amazon  analogy  analysis  aphorism  api  applicability-prereqs  applications  arrows  art  automata-languages  aversion  backup  bare-hands  benchmarks  best-practices  big-picture  blowhards  books  browser  build-packaging  business  c(pp)  caching  career  carmack  certificates-recognition  characterization  checking  checklists  classification  cocoa  code-dive  code-organizing  commentary  common-case  communication  comparison  competition  compilers  complexity  composition-decomposition  computation  computer-memory  concept  conceptual-vocab  concurrency  confluence  contrarianism  cool  correctness  cost-benefit  coupling-cohesion  cracker-prog  critique  cs  culture  dan-luu  dark-arts  data-structures  dataviz  dbs  debate  debt  debugging  deep-learning  design  desktop  devops  devtools  discipline  discussion  documentation  DSL  duplication  editors  electromag  engineering  erik-demaine  error  error-handling  essay  examples  expert-experience  explanation  exposition  extrema  facebook  flexibility  flux-stasis  formal-methods  frameworks  frontend  functional  gallic  game-theory  games  gcc  git  golang  google  gradient-descent  graphs  greedy  ground-up  guide  hardware  haskell  hg  hn  homo-hetero  howto  ide  ideas  identification-equivalence  IEEE  impact  info-foraging  init  integration-extension  interview-prep  intricacy  investing  ios  iteration-recursion  javascript  jobs  jvm  learning-theory  legacy  let-me-see  libraries  linear-algebra  links  linux  list  llvm  local-global  long-short-run  machine-learning  management  math  math.CA  math.CO  measure  mechanism-design  memory-management  metabuch  metal-to-virtual  metrics  microsoft  minimum-viable  models  multi  networking  nibble  nitty-gritty  ocaml-sml  oop  orders  org:com  org:med  os  oss  osx  p:null  p:someday  parsimony  performance  planning  pls  plt  pragmatic  presentation  prioritizing  probability  problem-solving  productivity  programming  project  python  q-n-a  qra  quality  quixotic  rand-approx  random  reading  recommendations  recruiting  reduction  reference  reflection  repo  retrofit  review  rhetoric  rigidity  rigor  s:***  saas  scala  scaling-tech  sci-comp  search  sequential  shipping  simplification  slides  software  spreading  stackex  startups  state  static-dynamic  stories  structure  summary  sv  system-design  systems  tcs  tech  tech-infrastructure  techtariat  terminal  things  thinking  time  time-complexity  time-preference  tools  top-n  tradeoffs  trees  trends  tutorial  twitter  types  ui  unit  unix  vcs  video  visualization  web  whole-partial-many  wiki  workflow  working-stiff  worrydream  yak-shaving  🖥 

Copy this bookmark: