3 ms·
So many unreadable and confusing code bases exist precisely because people made that assumption. For example, in the case of "name" there are typically many di
by hellofunk 10y ago
So many unreadable and confusing code bases exist precisely because people made that assumption.
For example, in the case of "name" there are typically many different things that need a "name" in the same context. First name, last name, etc. "name" by itself (and other short names) is honestly asking for lots of headaches in the long run.
- jstimpfle 10y agoThe CRUD database tables I make usually have "id" and "name" columns. "name" is always a human-readable descriptive string (few words). No need to have a more specific name for what "name" is. If you write SQL, you can disambiguate by table name prefix. If you iterate over result sets for example in python, you can easily be more specific on tuple destructuring time ("for personName, carName in ..."). When defining a table "Person", I consider it bad style to prefix all column names with "person". Btw this overzealous disambiguation falls flat as soon you do a self-join.
- hellofunk 10y agoA DB has a lot more obvious and strict context than a file of source code, and the law of demeter typically doesn't affect DB contexts as much as it does code, in practice. In real code, it's unwise to expect the reader to study context just to parse a name.
- jstimpfle 10y agoAre you agreeing with me here? I think so but can't tell for sure...
- hellofunk 10y agoI'm saying that a DB's organization is not the same as that of source code, and that surrounding context is a fundamental part of working with a DB and reading its layout, so perhaps the naming rules can be relaxed a bit in some cases.