public
/
cookiecutter-data-science
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix typo

This commit is contained in:
Isaac Slavitt 2016-04-23 16:41:01 -04:00
parent 8a5a03ef78
commit 54385320c1
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/docs/index.md
View File

@ -4,7 +4,7 @@ _A logical, reasonably standardized, but flexible project structure for doing an
## Why use this project structure?
We often think of data analysis as just the resulting report, insights, or visualizations. Even though these end products are generated by code, it's easy to focus on making the products _look nice_ and ignore the _quality of the code that generates them_. While these end products are generally the main event, **code quality is still important**! And we're not talking about bikeshedding the aesthetics or pedantic formatting standards — it's ultimately about correctness and reprodcibility.
We often think of data analysis as just the resulting report, insights, or visualizations. Even though these end products are generated by code, it's easy to focus on making the products _look nice_ and ignore the _quality of the code that generates them_. While these end products are generally the main event, **code quality is still important**! And we're not talking about bikeshedding the aesthetics or pedantic formatting standards — it's ultimately about correctness and reproducibility.
It's no secret that good analyses are often the result of very scattershot and serendipitous explorations, tentative experiments, and rapidly testing what works and what doesn't. That is all part of the process for getting to the good stuff, and there is no magic bullet to turn data exploration into a simple, linear progression. That being said, once started it is not a process that lends itself to thinking carefully about the structure of your code or project layout.