[flagged]
Jokes and Humour in the Public Android API
61–70 of 172 posts
Re: Jokes and Humour in the Public Android API
#62public static final String DISALLOW_FUN The default value is false. [...] Type: Boolean [...] Constant Value: "no_fun" Source: https://developer.android.com/reference/android/os/UserManag... --- How the hell did this pass code review? Are booleans strings on Android?
> How the hell did this pass code review? Are booleans strings on Android? You are misreading the documentation, it's a key/value API. `DISALLOW_FUN` is the string key you pass to `setUserRestriction`, which takes a boolean value.
That makes more sense. Thanks.
Re: Jokes and Humour in the Public Android API
#63Earlier quoted context omitted.
Live a little. When you've passed away, was all the seriousness paid off? That said, funny code should still work
Who cares what happens after you’ve passed away. You’re dead.
Only the things that remain of you after death really matter, everything else will have gone completely then anyway.
Re: Jokes and Humour in the Public Android API
#64Notice how pretty much none of these are added in the last 10 years? Android's become 'more mature' - ie. Boring, and the joke to code ratio is dropping rapidly.
Good, I hate ‘funny’ code. Just get to the point, I’m not here for someone’s notionally hilarious inside joke from 18 years ago.
I couldn’t agree more. I work in a codebase that has a handful of these “fun”-named functions/concepts and I hate it. It wasn’t funny the first time I came across it (just very confusing) and it’s not fun having to explain to new hires why a few things are named the way they are.
It needlessly complicates reading/following the code. Even if you explain the naming back at where you define the function/variable it add an extra click-through/hover to read that and an extra translation you have to do in your head when you read the “fun” variable name in the future.
One example is we have a flag called “dinnerbell”. What does that do? It tells the server receiving that flag to “come and get it”, “it” being the full data object instead of just getting a delta. It could have been called a whole slew of other things that would make more sense.
Re: Jokes and Humour in the Public Android API
#65Earlier quoted context omitted.
> How the hell did this pass code review? Are booleans strings on Android? You are misreading the documentation, it's a key/value API. `DISALLOW_FUN` is the string key you pass to `setUserRestriction`, which takes a boolean value.
That makes more sense. Thanks.
Also this is an enterprise policy constant, so it gets sent (and configured) as string/string dictionary via REST API from MDM backend. That's mostly because the constants can be of mixed types (e.g. "MAX_PASSWORD_CHARS" : "1", "DISALLOW_NETWORK_SWITCHING: "true" - example, constants not actual).
Re: Jokes and Humour in the Public Android API
#66Earlier quoted context omitted.
Ah I see you're one of those who would enable `UserManager.DISALLOW_FUN`! I personally quite enjoy a bit of whimsy in code. What we do (mostly) isn't that serious (modulo those, including me once upon a time, who work on literal life and death software)
I agree with you. The dinosaur game in Chrome is the classic example; turned off because schools threatened to not buy Chromebooks if kids could play a game in the browser. At least it seems to be a setting now, so your individual locality can decide if fun is allowed.
That’s quite different from what we’re talking about though. That’s adding games or fun into your product whereas in this specific sub-thread we’re talking about naming code concepts (functions, classes, variables, enums, etc) funny things.
Re: Jokes and Humour in the Public Android API
#67Notice how pretty much none of these are added in the last 10 years? Android's become 'more mature' - ie. Boring, and the joke to code ratio is dropping rapidly.
Good, I hate ‘funny’ code. Just get to the point, I’m not here for someone’s notionally hilarious inside joke from 18 years ago.
Me too. Professional code isn’t the right place to insert your personality or sense of humour.
Re: Jokes and Humour in the Public Android API
#68Earlier quoted context omitted.
Good, I hate ‘funny’ code. Just get to the point, I’m not here for someone’s notionally hilarious inside joke from 18 years ago.
Ah I see you're one of those who would enable `UserManager.DISALLOW_FUN`! I personally quite enjoy a bit of whimsy in code. What we do (mostly) isn't that serious (modulo those, including me once upon a time, who work on literal life and death software)
I think that's a big line between people who work as software engineers becuase they enjoy the work and want to build something and folks who go there to punch the ticket and run back home as soon as possible.
The second group doesn't want to deal with "all the fun crap" and "distractions" that stand in the way of them marking a bug fixed (or, god forbid, actually getting extra bugs/work assigned because some "fun" code might break or cause confusion).
As teams and companies grow, the second group usually outgrows the first and the first group moves on to reform into smaller teams working on something else again.
Re: Jokes and Humour in the Public Android API
#69How is someone writing an article about Android source code node nerdy enough to know what a Tricoder is? I don’t buy it
Right? It could be an attempt at humor, but it could also be someone who is naive of culture before 2003. I lost some respect for the author at that point...
This is so american/age centric please reconsider dispensing respect based on who watched the same TV shows as you growing up
Re: Jokes and Humour in the Public Android API
#70Earlier quoted context omitted.
Live a little. When you've passed away, was all the seriousness paid off? That said, funny code should still work
There's a middle ground for sure. I've left a few witty comments and loglines in my time. But I've also had to debug a Delphi unit which returned error codes inspired by the magical supercomputer Hex from the Discworld novels. "Divide by cucumber error" is not a decent enough representation of a module's internal state, no matter how funny you think you are.
"Divide by cucumber error" sounds like a great string to grep for - so actually helpful for developers to find the place in the code that threw it.