Skip to contents

References

references.Rmd

Resources

“As you start to run R code, you’re likely to run into problems. Don’t worry — it happens to everyone. I have been writing R code for years, and every day I still write code that doesn’t work!” - R for Data Science

Correspondence tables

Topic stata Link paper
OLS reg lm NB Ruhm (1996,JHE) Card (1993, NBER)
sandwiches robust cluster, vce vcovCL, vcovHC NB Peri (2012,ReSTAT) Krueger (1999, QJE)
instruments ivreg 2sls ivreg NB Card (1993, NBER)
testing test linearHypothesis NB Ruhm (1996,JHE)
probits etc. probit glm NB Mroz (1987, ECMA)
panel data xtreg, xtivreg plm NB Ruhm (1996,JHE) Cornwell and Trumbull (1994)
DiD reg lm NB Draca et al. (2011) Card and Krueger (1994)

Coding wisdom

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. — Martin Fowler

Hedley Wickham writes: One of the most obvious ways to improve the quality of an application is to improve the readability and understandability of its code. The best programmers in the world can’t maintain a code-base that they can’t understand, so this is a good place to start.

Being a good programmer means developing empathy for others who will need to interact with this code-base in the future (even if it’s just future-you!). Like all forms of empathy, this takes practice and becomes easier only after you’ve done it many times. Over time, you’ll start to notice that certain practices improve the readability of your code. There are no universal rules, but some general guidelines include:

  • Are the variable and function names clear and concise? If not, what names would better communicate the intent of the code?
  • Do I have comments where needed to explain complex bits of code?
  • Does this whole function fit on my screen or could it be printed on a single piece of paper? If not, is there a way to break it up into smaller pieces?
  • Am I copying-and-pasting the same block of code many times throughout my app? If so, is there a way to use a function or a variable to avoid the repetition?
  • Are all the parts of my application tangled together, or can I manage the different components of my application in isolation?

The Zen of Python

The principles (import this) are listed as follows:

    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one– and preferably only one –obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than right now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea – let's do more of those!

Other maxims

  • DRY: Do not Repeat Yourself
    • If you use a functionality more than once, write a function for it.
  • KISS: Keep It Simple, Stupid
  • SoC: Separation of Concerns / Modularity
    • A function should only do one thing.
    • Scrolling sucks.