kagis 'C++ naming conventions'
this post was submitted on 20 Dec 2024
177 points (97.8% liked)
Programmer Humor
19817 readers
52 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
Having dealt with this drama before, and as team lead currently, as soon as this project began, the first thing I did was set up a linter with very specific rules. If a dev doesn't agree with the rules defined there, too bad. They're there to prevent this kind of drama, and to make peer reviews more focused and productive. I don't wanna see PRs about syntax. They're nearly always just a difference of opinion.
If I ever get around to writing my own language, it's going to take parse trees off the disk, so people can deparse them into whatever they want and STFU.
When I was a mod on Reddit we had a slack channel, one of the new mods got outed and shamed for a post where they were a dick at a show, the sub turned on them so we had to remove them, the head mod scolded them while we were all silent watching, it felt like we were kids hiding on the top of the stairs watching a sibling get scolded.
Oof. This is a pet peeve of mine.
As manager, I shut this conversation down via direct messages to each team member involved.
I remind them that they agreed during retro to live with the current set of decisions for exactly two weeks until next retro.
I don't dictate much, but I do dictate that Slack isn't an acceptable place for this kind of discussion, on my team.
The only related thing, that belongs in slack, on my team, is a link to the current accepted team standard - which will be open for review and changes again during next retro.
Alternately, if there's no standard for this yet then my team knows they're encouraged to wing it until we discuss at next retro.
And yeah, I've had to open an issue to revisit a variable name after retro, lol.
My team are an opinionated bunch, and they're often perfectionists.
You allow naming schemes to change every two weeks? That's just insane! You might as well not have a naming convention then, since the project is going to be full of different conventions.
You might as well not have a naming convention then, since the project is going to be full of different conventions.
Oh, I skipped this. Lol. Obviously not. As a team, they can implement whatever convention change they want, every two weeks.
As manager, I expect them to update all active projects, in their entirety, to the new convention, each time.
And as I mentioned in my other comment, if their test coverage isn't at a level that makes me confident in that kind of global change (70% tends to be plenty), then I reserve the right to table it - until they bring the test coverage up (on all impacted projects).
You allow naming schemes to change every two weeks? That's just insane!
Yes. Everything is open for discussion every two weeks, during our retrospective meeting.
Of course, that doesn't mean things will actually change that fast.
But let me push back a bit, too - a global find and replace on our entire source code would take maybe a couple hours. A substantial naming convention refactor would take maybe a couple of days.
The reason we don't do anything that aggressive is we don't trust ourselves to make the change correctly - not because it's actually a difficult change to make. Where our test coverage is where it should be, it's a perfectly safe change.
If my team tells me (in agreement with each other) that a change like that is necessary, my job is to go make time for them to get it done.
On the scale of requests my team has given me, a couple days to rename some variables is no big deal.
There's absolutely stuff I won't allow, as team manager, but flip flopping on variable naming is owned by the team, and I would allow it, within reason.
A couple fair-game manager reasons I might shut down a variable naming convention change are:
- The test coverage on that part of the code doesn't inspire enough confidence to make any unnecessary changes. Improve the test coverage, and we will revisit.
- (Hypothetically) We made two similar changes in recent memory, and as manager, this is affecting our team reputation. Let's make a plan to make this change in a way that does not impact our team reputation.
Anything short of those two scenarios, and - should my team present it to me in agreement - I go make the time for them to make the change.
A shorter version is: I'll discuss and do my best to support whatever my team wants to change - every two weeks. It's a small price to pay for some peace for 9 out of every 10 business days! (And honestly, it's a big part of my success formula.)
Let me tell you: I’m currently developing a user-defined, recursive form, and most of the trouble with that stems from the fact that I don’t have a good name for the repeatable part of that form (as opposed to a static part) and the thing the form is embedded in.
Variable names do matter.
Camel_Case
That's actually offensive.
I just use UUIDs
I'm just gonna say it: fuckYourCamelCase
Uhh, why?
Proudly thinks that __M_fs_stdbuf_t is perfectly readable.
I’d like to buy a vowel
Instructions unclear. You have been assigned: ǿ. You now owe a million Danish kroner.
Only if it stands for motherfuckers standard buffet.
A buffet of underscores maybe.
I don't get this meme at all... What am I expected to see in this picture? Or how am I supposed to interpret it?
If you don't work on software projects with other people then it won't make any sense to you.
I've been doing it for 2 decades, still don't get it. So maybe you can enlighten me what IT has to do with naming stuff in code?
$goddamnitJeffStopChangingMyFuckingVariableNames = 1;
One day I will see this drama... Until then, it will remain only in memes.
Missed opportunity to title post in the style of bad variable name.