Active Entries
- 1: Surge Pricing for Grocery Stores is a Disaster Only Psychopath MBAs Could Love
- 2: Antarctica Day 7: Swimming In the Antaractic Seas
- 3: Restarted my yoga classes, and I discovered I'm a total wreck
- 4: Antarctica: Getting To the Boat and the Disaster That Awaited
- 5: The Enshittification of All That Lives
- 6: How the green energy discourse resembles queer theory
- 7: Tori's Sake & Grill (restaurant, review)
- 8: I'm Not Always Sure I Trust My ADHD Diagonosis
- 9: You can't call it "Moral Injury" when your "morals" are monstrous
- 10: Ebay vs Newmark: You're all just cogs. Accept it. There is no joy in it, but you have no choice.
Style Credit
- Base style: ColorSide by
- Theme: NNWM 2010 Fresh by
Expand Cut Tags
No cut tags
no subject
Date: 2013-02-21 06:00 pm (UTC)Using aliases for the purposes of documentation is a fairly standard practice.
In the code snippet provided, presumably hlf is an alias for the center of the sprite, indicating that we are using half it's width and height to position the sprite. I could certainly take issue with the use of variable names here. It might be that the person who wrote the code struggled to figure out what cx/cy where, and when they did, they chose to document that in the code. It's not the best job I've seen at doing that, but that is certainly a standard idiom that used commonly in programming. In fact, I'll be happy to admit that I used the hlf identifier as a hint when trying and figure out what the code was doing. As an identifier, hlf carries more semantic information than cx/cy.
I will admit, I have, on occasion, created my own version of object, either so I can extend it with additional methods, or reformat the data so that it make more sense internal to the application I'm developing.
In this case, the object was not extended, but rather narrowed, something which is a not unreasonable thing to do.