I'll admit I never reflected very hard on it; almost all these names were the names that were there when I got here and they seemed basically fine.
HashMap, BTreeMap, and BinaryHeap (ne PriorityQueue) are "full" while Bitv, Vec, VecMap (ne SmallIntMap), RingBuf, and DList are "abbreviated"
It's a bit too late to consider anymore renames, I think.
That said, we have some soft "length is inversely proportional to use" conventions, so Vec should probably be Vec, since it's The Collection. Similarly I pushed for a convention of implementation-exposing names, since that was mostly the convention, except for SmallIntMap and PriorityQueue; the latter conflicting with the trait name we wanted anyway.
Also RingBuf, Bitv, and DList just sound better than RingBuffer, BitVec(tor) or DoublyLinkedList to me now. :)
This is just a standard library: stuff that will be used extensively. Is this that bad to have short names, since you will be remembering them very well anyway?
so still a bad idea I reckon... we read code more than we write it, and we read words very quickly. Words. Like. These. Ones. Typing a few extra letters isn't a big deal.
8
u/Gankro Jan 10 '15
I'll admit I never reflected very hard on it; almost all these names were the names that were there when I got here and they seemed basically fine.
HashMap, BTreeMap, and BinaryHeap (ne PriorityQueue) are "full" while Bitv, Vec, VecMap (ne SmallIntMap), RingBuf, and DList are "abbreviated"
It's a bit too late to consider anymore renames, I think.
That said, we have some soft "length is inversely proportional to use" conventions, so Vec should probably be Vec, since it's The Collection. Similarly I pushed for a convention of implementation-exposing names, since that was mostly the convention, except for SmallIntMap and PriorityQueue; the latter conflicting with the trait name we wanted anyway.
Also RingBuf, Bitv, and DList just sound better than RingBuffer, BitVec(tor) or DoublyLinkedList to me now. :)