Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Absolutely could not agree more. The thing that even clearly named schemas, tables, columns, etc. miss are context and intent. If you have that context already you probably don't need much by way of documentation. But as someone that gets called into clients to work through their databases, I spend a lot of time trying to figure that context and intent. If it's documented, that learning curve is reduced greatly.

I usually do these comments on all objects regardless of how obvious the names and code may be. If even only for the reason of ensuring that doing this discipline remains second nature. I also like to remember that I'm not doing this for me, but rather for the client's team and others that come after me to work on things.



This. Database impact analysis is painful enough without a developer assuming 5 years ago that their table was so obvious it didn't need a comment.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: