Am I allowed to whine about work? At some point before I arrived, someone started the idiom of using self as a parameter name in our helper functions. This legitimately confuses me as "self" is a reserved word in our language that specifically points at the current instance. In general, it's been used to keep access to the current database connection, which is cool, but there's so many other ways we could do that. Pass in the db_conn as an object, or rename all instances of self as a parameter outside of a class as handler, since that's what we're actually needing. Why is it so hard for people to keep things meaningful?
That sounds like the kind of thing that would justify going through all the source and ripping out any use of that word that wasn't the builtin. Ugh.
I doubt I'm ever going to have the free time to really clean that up. Truthfully, our conventions are incoherent as fuck and I'm so glad I'm the primarily developer on the new apps, because I can actually insist on conventions. Like letting dictionary formatting be its own thing, in its own module, where everyone knows where it is.
Who else loves recruiters who obviously don't know what they're hiring for? Or, you know, seem able to pass a 101 CS course. Today's email included these bullets: The asking for Java and "Java scripts" on one line when they had just mentioned scripting languages. . . worries me. It's also a contract position in the Bay Area, so. . . yeah, no thanks.
... seriously? That's dreadful. Last (only) time I was jobhunting, I was looking for entry-level positions, so I think I missed a lot of craziness. :\
Most of the time, the hiring manager doesn't actually want all that, it was put in by corporate HR or distorted by the agency. Sometimes, the hiring manager is the one at fault and you don't want to work there.
My entry level search was pretty much exactly this crazy. Because juniors are low priority, they're WAY more likely to be screened by the HR side of a company, who is less likely to know what the fuck is up. In other news, I just found the window splitting in my IDE and life is SO MUCH BETTER now. Also, I totally made a function of most of one of my handlers, so that we can reuse the code in at least two other places. Also, I think I'm on the line for turning our "queries" module (Which is not queries, it's a bunch of various helper functions) into a package that organizes them better.
. . . that's terrible. Goodness sake. :\ We just have very few entry level positions near me; I took the job offered by my third application / first interview, so I'm still pretty inexperienced on the job-search front. (And uh, hopefully it won't come up any time soon.) Also, that's awesome; organization is definitely nice. I need to go through the entire codebase and add comments, because my coworker is of the 'it should be obvious from looking at the code' school, and he wrote 90% of the code. =_= (Which, yeah, that's kinda true... but I've had to make flowcharts to understand fifteen layers of dependent functions, because the variables are named weirdly and there aren't any top-level comments. :\ And at that point it's just an enormous waste of time if anyone else ever needs to understand that code. Cool guy, good coder, but he's a triage guy, not a long-term-organization guy, and it is a little maddening.)
If you can't understand it from reading and docstrings, someone didn't do their job. I am totally of the "it should be obvious reading it" school. But the thing is: Code: while running: delta = clock.tick(60) / 1000.0 spawn -= delta display.fill(GRASS) if spawn <= 0: baddies.add(ghosts.Spirit(randint(100, 400), randint(100, 400))) spawn = 5.0 baddies.update(delta) for baddy in baddies.sprites(): if not play_field.colliderect(baddy.rect): baddies.remove(baddy) baddies.draw(display) pygame.display.update() for event in pygame.event.get(): if event.type == QUIT: running = False You should be able to understand only if the functions and variables are well named.
There are some things that aren't obvious from code inspection, though, and those are the kind of things that should go in comments. E.g. workarounds for bugs in dependencies, avoiding compiler bugs, undocumented features of the OS, things like that. They're not in docstrings because they're not about the function / method / object's documented behavior, but they need to be in there as notes for the next maintenance programmer. I tend to feel that docstrings are there for the user, and document external behavior, not implementation. User as in "programmer using this code", that is.
It sounds like docstrings in Python are what I'm talking about as "comments". We don't really have any. (ETA: The languages I'm familiar with don't really distinguish between user-level documentation "comments" and developer/maintenance-level "comments", so I'm used to using the same terminology for both. Or at least, I haven't ever heard of a distinction. Sounds damned useful though.)
Todays silly snippet: Code: value = True if not result else False Now refactored to: Code: value = not result
And in news: The button has been pressed. The project is released: https://itunes.apple.com/us/app/star-wars-card-trader/id946777364?mt=8
Today I learned that every major operating system represents newlines differently. :| This seems kinda ridiculous.
Well, yes and no. Anything Linux and OSX are both unix style line endings (\n), old Mac was \n\r and Windows is \r\n. So they all have similar line endings? (But the unix one is the right way.) /Unix snob.
... and apparently we're all stuck with this forever because nobody knew how to write printer drivers in the sixties. Programming history is weird. (Unix is usually the best way. Sadly, stuck with Windows at work, as is the usual run of things.)
My favorite example ever of "it should be obvious" backfiring: There was an event in hack which was pretty rare. Spoilers file said it was 2 in 500 (yes, really!) in the code. I eventually found the code: Code: if (!rn2(500)) Only... That's a 1-in-500. "rn2()" was a 0..N-1 RNG. Someone saw "2" and interpreted it as data.
