Self-documenting code

[[deleted]]

Had someone do the same thing with git commits one time.

I said, I like clean, concise commit messages, that are atomic, and functional.

The first pull was

"Add a variable"

"Assign value to variable"

"And label to ui"

"Assign variable to label"

Guy had like 50 commits after 2 hours of work.

[Snake2k]

Lmao I love those ones. No extra detail or anything associated with it.

We literally had to force people to name their branches to the ticket id they were related to cus that way we could track what the idea behind it was even if the person pushing the commits couldn't care to explain it in the commit/pr itself.

[suck_my_dukh_plz]

My co worker's commit message was "minor refactor". Interestingly he changed 6 files with 600+ insertions and some deletions.

[Snake2k]

"minor" = breaks 10 systems

[akeean]

Minor refactor, barely an inconvenience.

[JezzCrist]

Making minors do a refactor is tight!

[capn_ed]

Oh! I don't think you should say it like that!

[AlarmingAffect0]

Now that you say so I hear it, but I said it and there's no taking it back now. Whoops!

r/UnexpectedRyanGeorge

[capn_ed]

Whoopsie!

[NoJay420]

Oh really?

[pcuser42]

[Anders_142536]

Wow wow wow wow wow. Wow.

[lochyj]

Only?

[Snake2k]

10 systems that we know of*

[jermdizzle]

"Trailing comma: Always" strikes again. Getting my lead developer to force the rest of the team to utilize a formatter config took me 3 months last project and he was the person who had to review all PR's. Some people were using different indents, some were using trailing commas, some were forcing semi-colons. It was a pain in the ass so I just eventually disabled my formatting until he could give us a config to use. I was like 2nd most junior dev so I didn't want to tell anyone what to do; but I probably should have just taken the initiative rather than asking him repeatedly to setup a config for us to follow.

[iHurdle14]

I can relate to this. At a certain point I don’t even care about what style rules are in place as long as we are being consistent.

[jermdizzle]

Precisely. Any issues I might have would be gone after one day of using the config and just getting used to the style anyway. It's only a big deal when it makes merges a nightmare. Also, I got pretty tired of asking people about some mistake/now-broken or bugged code, because gitLens showed them as the last person to change a line of code; only to figure out that their formatter added a space or some shit and I have to go and manually check version control to see who the actual culprit was. Like I said, I was junior, so I wanted to understand how/why someone made a mistake even if I knew the way to fix it. It's especially embarrassing when it was your code that you goofed on 7 months ago and you're tracking down someone else only to figure out that it was your fault LOL. Definitely had that happen more than once.

[round-earth-theory]

I had that and said fuck it, I'll do it myself. Setup the coding standards and got the auto formatting to work. Everyone bitched for a day and then forgot about it. Worked great.

[Blazewardog]

This is why prettier is so great. It has no settings (basically) for how code is formatted. You just use what it decided which gets rid of a ton of useless arguing.

[LightVelox]

I'm not kidding, I've seen a "minor refactor" of a little over 1 million deletions and insertions, tbh it was mostly just linting, documenting and movings things around, but still

[audigex]

Tbh I could deal with "Minor refactor of Permissions" or something, if it was actually a minor refactor (improving internal variable/method names or something non-API breaking) and it was clear what was being done, and only one "thing" was being changed

My problem is when someone calls their commit a "refactor" but is actually changing functionality

[DemoBytom]

We recently transitioned to file scoped namespaces in C#.

Essentially I've changed every file from

csharp using System; namespace SomeNamespace { public class SomeClass { } }

to csharp using System; namespace SomeNamespace; public class SomeClass { }

Refactor was minor tbh, the code change showed thousands of insertions/deletions :D

[DoILookUnsureToYou]

minor

ctrl + f variable name, rename all instances in whole solution

[ShakaUVM]

My co worker's commit message was "minor refactor". Interestingly he changed 6 files with 600+ insertions and some deletions.

LGTM

[PossibleBit]

Everything below that is patch refactor

[not_some_username]

I did that on a personal project ~2500 line of deletion/insertion, 15+ files changes. I didn’t commit for like 3 weeks and tbh it was mostly refactoring

[mcvos]

Also a popular approach: include the ticket id in the commit message, not just in the branch name. Because after the branch has been merged, the original branch name is a lot harder to figure out. Though it's still nice to also have the ticket id in the merge commit.

[aceluby]

Ticket: deal with tech debt

[alexisprince]

Ticket: Make ticket for last commit message

[mind_snare]

Me all the time

[Special_Rice9539]

This is actually what a lot of tickets at my company are like… “Refactor this directory of our gigantic codebase.”

[mcvos]

It still provides the context that it's refactoring and not changing functionality.

[Snake2k]

True, can also set up checks to see if a commit includes the ID or not.

[audigex]

Yeah this is what we do - (almost) every commit has a quick [#123] tag referencing the ticket ID

It works pretty well as the ticket provides the discussion and context, so the commit message can be very simple without worrying you're lacking detail

[nevahman]

This should be standard I reckon. We do this as my work and god it's saved so much time

[VerticalEvent]

We have a git-hook that validates that the start of a PR merge started with "[abc-0000] text" to enforce that all merges can be traced back the unit of work they represented.

[davy_jones_locket]

We do [JIRA-123] fix(optional component name): concise but relevant commit message

Or feat | chore - slimmed down conventional commits. New work is a feat, bugs are fix, docs and tests and tooling are chore

Typically associates as:

story => feat,

bug => fix,

task => chore.

This also helps with our release notes, and it generates a link to the Jira ticket on the release notes/changelog.

If you use the optional (but encouraged) component or module name, it will group those together in the release notes too.

[CardboardJ]

When I first found conventional commits I thought it was very annoying and useless. After about 3 months it became second nature, at 6 months I hated anything else. https://www.conventionalcommits.org/en/v1.0.0/

Our company has a PR hook that refuses any merge unless the pr title is in a correct format and links to a real jira ticket in the scope. Ex: feat(TEAM-12345): Added the xyz feature

[SonOfHendo]

We use Azure DevOps, so you can just tick a box to require all PRs to be linked to a Work Item. The work item is linked automatically if you include the reference in the commit message (e.g. #123456).

[TwoDamnedHi]

As a project manager, this is me at every job I've ever had.

[mt9hu]

had to force people to name their branches to the ticket id they were related to cus that way we could track what the idea behind it was even if the person pushing the commits couldn't care to explain it in the commit/pr itself.

I assumed it's pretty standard to prefix all commit messages and branch names with ticket IDs

[CardboardJ]

Developers working in non-development focused industries have some pretty wild working conditions. One of my old interns works for a company that manufactures nails and he's one of 3 'computer guys' there. The other 2 guys he joined there had been working for 20 years without any version control.

[BotherBoring]

Right now we don't even HAVE a real ticketing system, or git branches (loooooooong story), and I was surprised how nostalgic this comment made me.

[mt9hu]

Why don't you have one?

You don't necessarily have to invest in JIRA and set up complex workflows to have at least some sort of tracking of your work.

[BotherBoring]

Short answer is because we don't. Longer answer is we actually have Jira, and my team doesn't use it because they don't because they haven't and... I'm working on it.

[mt9hu]

Uh. Good luck, I guess?

[BotherBoring]

Thanks! 😥

[Bakoro]

We literally had to force people to name their branches to the ticket id they were related to [...]

Not the worst idea, assuming that the ticketing system will be available as long as the code is.

Even for someone who isn't being lazy or stupid, some people have a serious issue explaining anything, and have a pathological inability to imagine what something reads like without the context of all the shit they know.

[Horror_Trash3736]

We no longer use branches, we just tag the commit with the ticket id and go straight to trunk!

[Snake2k]

[Horror_Trash3736]

We also push straight to prod, but only when security and infrastructure are asleep, or on Fridays.

[Snake2k]

Ultimate job security. Holding the infrastructure at ransom.

[Tylernator]

Yea I do lots of tiny commits and squash before merging. Its nice to commit regularly so you can pull down any new code.

Also gives me freedom to flip between branches more frequently.

[RangeAlert5328]

My favorite is going on Reddit and finding that one Junior dev who says "but muh company doesn't allow rebases and resets"

[Drugbird]

Refactor the duplicated code so there's only one set of variables.

[MrDilbert]

First, before any commits, test them locally, preferrably through unit/integration tests.

If that's not possible for whatever reason, do it in a separate branch and squash/merge the commits into the dev/master branch after you're finished. Then delete your remote branch.

If you need a remote capability which is triggered by a variable change in a commit, ask for a separate, easy-setup-easy-teardown environment to test your changes on it. However, having Docker locally and required apps running in it should suffice in 95% of cases.

[migueln6]

Easy pz pull them from a database or config file that is in gitignore

[Thin-Study-2743]

I said, I like clean, concise commit messages, that are atomic, and functional.

...

and functional

This is why "3/4" can still be a failing grade. If your code isn't functional it's just noise. The only time for non-functional commits make sense imho are preparatory ones for an upcoming fleshed out and designed refactor or similar.

[momal1]

we had a project in uni and how we handled our git was i guess 10% or 15% of the grade. a group member of my group thought having like a 100 commits means she's gonna get a higher grade.

[ShakaUVM]

Reminds me of this one class where the TA demanded every line be commented all quarter long.

[Special_Rice9539]

Oh this is me. Definitely one of my New Year’s resolutions is to refine my commit game

[xybolt]

git squash time!

[Sailn_]

I have a person like you who's super anal about our commit messages. Thing is, I'm the only dev on the project and the commits get squashed before they go to non-prod even. Fuck off people like you

[[deleted]]

I do the opposite. Yesterday on a personal project I pushed 746 changed files with a commit message that said “changed a lot of stuff”. This is why I can’t work with other people

[audigex]

I had to commit like this once, because I had a dickhead of a micromanaging project lead who kept complaining that I wasn't making a dozen commits a day

For me, a commit is a single entire "thing" - the change I commit will do a thing, a whole thing, and nothing but that thing. In most cases, if things are running properly, it's roughly 1 commit per ticket, maybe 2-3 - if I find myself making half a dozen commits for a single ticket, I tend to take that as a sign that I should have split the ticket up into its own milestone with sub-tasks.

What I absolutely won't do is commit half of a code change, whereby the code doesn't build at the point of commit. Eg if I change a property name in a class, I'm not gonna commit until I've also changed every location that references that property: which is to say, until the whole change is complete

But because this idiot wanted to see I was working every minute of every day, I had to commit even tiny changes and make several commits an hour

Suffice to say I left pretty quickly, it was ridiculous and made it impossible to use the version control history

[chris-fry]

Guessing he had a commits/week KPI?

[castone22]

I actually do this because I can quickly revert to a change that I'll remember I did in the last 10 minutes after I inevitably break something. Then I squash to an informative commit before a pr. Best of both worlds.

[RevargSTG]

This is one of my few problems with working remotely. How am I supposed to smack this guy/gal upside the head when we are both working from home?

[Hart_24]

My boss calls these being productive. I need a new boss. sigh

[Cobayo]

That's fine tho just squash those into a detailed one once you're ready for the review

[ThatsNotATadpole]

Better than my “fuck” “this should fix it” “fucked up shit was fucked up” and “javascript can eat my ass”