Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

It's more like this conversation, which I've had several times:

User: "Hey, X no longer does Y when you Z. Why did that change?"
Me: "I'm not really familiar with X... Let me check and get back to you."
*looks through code, finds a point in time when X did Y when you Z'd*
*looks for commit when that change occurred, finds it, reads check-in message by a developer who's long gone*
"Changed X to no longer Y when you Z"

No context, no explanation for why the change was made. It's less of a big deal if the check-in is tied to a work item, and the change is relevant to the work item, but sometimes you just get a change that's totally devoid of context. Then you have to go back to someone and say "I don't know, <former developer> made that change," which leads to having to figure out why the change was made and whether the change needs to be undone. If the message was "Changed X to no longer Y when you Z because of A, B, and C", then you have a reasonable basis for evaluating the ramifications of changing it back.

# ? Jan 3, 2013 19:45

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 21:07

Bunny Cuddlin: Dec 12, 2004

Ithaqua posted:

It's more like this conversation, which I've had several times:

User: "Hey, X no longer does Y when you Z. Why did that change?"
Me: "I'm not really familiar with X... Let me check and get back to you."
*looks through code, finds a point in time when X did Y when you Z'd*
*looks for commit when that change occurred, finds it, reads check-in message by a developer who's long gone*
"Changed X to no longer Y when you Z"

No context, no explanation for why the change was made. It's less of a big deal if the check-in is tied to a work item, and the change is relevant to the work item, but sometimes you just get a change that's totally devoid of context. Then you have to go back to someone and say "I don't know, <former developer> made that change," which leads to having to figure out why the change was made and whether the change needs to be undone. If the message was "Changed X to no longer Y when you Z because of A, B, and C", then you have a reasonable basis for evaluating the ramifications of changing it back.

This too. It leads to poo poo like "Well, we don't know why X no longer does Y. We'll change it back." and then two months later "Hey, so X can't do Y when you Z because blah blah blah" and the change echos back and forth, forever, wasting hours and hours of dev and QA time.

# ? Jan 3, 2013 19:48

Zamujasa: Oct 27, 2010; Bread Liar

Ithaqua posted:

It's more like this conversation, which I've had several times:

User: "Hey, X no longer does Y when you Z. Why did that change?"
Me: "I'm not really familiar with X... Let me check and get back to you."
*looks through code, finds a point in time when X did Y when you Z'd*
*looks for commit when that change occurred, finds it, reads check-in message by a developer who's long gone*
"Changed X to no longer Y when you Z"

No context, no explanation for why the change was made. It's less of a big deal if the check-in is tied to a work item, and the change is relevant to the work item, but sometimes you just get a change that's totally devoid of context. Then you have to go back to someone and say "I don't know, <former developer> made that change," which leads to having to figure out why the change was made and whether the change needs to be undone. If the message was "Changed X to no longer Y when you Z because of A, B, and C", then you have a reasonable basis for evaluating the ramifications of changing it back.

This can tie in pretty well if you have an issue tracker and tie commits to it, even by just putting the issue number you're working on in the commit message. "#47 Changing foo to bar" and "#47 Changing baz to bar" (in addition to grouping by being on a separate branch) can really help with the digging.

E: This is basically what you're saying :downs:

Zamujasa fucked around with this message at 19:55 on Jan 3, 2013

# ? Jan 3, 2013 19:48

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

Zamujasa posted:

This can tie in pretty well if you have an issue tracker and tie commits to it, even by just putting the issue number you're working on in the commit message. "#47 Changing foo to bar" and "#47 Changing baz to bar" (in addition to grouping by being on a separate branch) can really help with the digging.

most of my commits are just that: "fixed #45 - Customers can't checkout", let the ticketing system provide context, which is what its good at and easily (hopefully) searchable, and let source control be good at controlling source.

# ? Jan 3, 2013 19:52

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

http://who-t.blogspot.com/2009/12/on-commit-messages.html

# ? Jan 3, 2013 19:54

how!!: Nov 19, 2011; by angerbot

Bunny Cuddlin posted:

This too. It leads to poo poo like "Well, we don't know why X no longer does Y. We'll change it back." and then two months later "Hey, so X can't do Y when you Z because blah blah blah" and the change echos back and forth, forever, wasting hours and hours of dev and QA time.

That seems like an argument in favor of documentation.

Documentation should go in the code, not in the commit history.

# ? Jan 3, 2013 20:08

Deus Rex: Mar 5, 2005

how!! posted:

That seems like an argument in favor of documentation.

Documentation should go in the code, not in the commit history.

instead of deleting lines, comment them out and add a 2-3 sentence comment above explaining why it was deleted

# ? Jan 3, 2013 20:10

Bunny Cuddlin: Dec 12, 2004

how!! posted:

That seems like an argument in favor of documentation.

Documentation should go in the code, not in the commit history.

What about my previous post? What is the argument against writing two sentence commit messages? It seems to just be "I don't want to"

# ? Jan 3, 2013 20:10

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

how!! posted:

That seems like an argument in favor of documentation.

Documentation should go in the code, not in the commit history.

You think documentation of changes made to code should go in the code?

edit: Deus Ex said it in a much better, snarky fashion.

# ? Jan 3, 2013 20:10

ToxicFrog: Apr 26, 2008

Zamujasa posted:

This can tie in pretty well if you have an issue tracker and tie commits to it, even by just putting the issue number you're working on in the commit message. "#47 Changing foo to bar" and "#47 Changing baz to bar" (in addition to grouping by being on a separate branch) can really help with the digging.

This is pretty much how it worked at the last place I worked, and in fact version control wouldn't let you make a commit without one or more associated issue numbers. It'd automatically add links to the issue(s) to the commit message, and the issue tracker itself would link back all of the relevant commits. It was pretty nice.

# ? Jan 3, 2013 20:14

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

how!! posted:

why would you need to look through commit history to fix a bug? Just fix the bug. I've fixed many bugs, and can't tell you of a single time where I had to look through the history in order to fix it.

When I first started out, I used to do the long, thorough commit message every time. Until I realized its just wasted effort.

Have you never been in an accidental commit war, or tried to look up an old implementation you deleted? A basic commit message makes navigating your VCS way easier.

Maybe two sentences is a bit overboard, but at least knock out a quick phrase to describe why you changed something. If you don't have a clear enough idea of why you made the change that you can punch in a few words, don't make the change.

# ? Jan 3, 2013 20:15

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

ToxicFrog posted:

This is pretty much how it worked at the last place I worked, and in fact version control wouldn't let you make a commit without one or more associated issue numbers. It'd automatically add links to the issue(s) to the commit message, and the issue tracker itself would link back all of the relevant commits. It was pretty nice.

Github works like this if you use their issue tracker. You can have a commit message with "Closes #128" in it and it automatically links to the issue, closes it, and links from the issue to the commit.

# ? Jan 3, 2013 20:16

Bunny Cuddlin: Dec 12, 2004

TFS allows easy linking/transitioning work items on commits too if you're in Microsoftland

# ? Jan 3, 2013 20:17

ToxicFrog: Apr 26, 2008

Thermopyle posted:

Github works like this if you use their issue tracker. You can have a commit message with "Closes #128" in it and it automatically links to the issue, closes it, and links from the issue to the commit.

Ours was close-by-default on every commit. You had to put "B#1234 noresolve" if you wanted it to update the issue without changing its status. :shepface:

I accidentally closed a lot of bugs my first month there.

# ? Jan 3, 2013 20:21

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

how!! posted:

why would you need to look through commit history to fix a bug? Just fix the bug. I've fixed many bugs, and can't tell you of a single time where I had to look through the history in order to fix it.

When I first started out, I used to do the long, thorough commit message every time. Until I realized its just wasted effort.

Tell me this again after working for a manufacturer of devices that are subject to FDA regulation :allears:

"Oh, you found this rare but very serious bug that can destroy patient data? Who introduced it at what time, and what was the next released version that contains the bug?" Management would then talk to the sales team to find all affected customers (since not all of them upgraded the devices' software for every minor version) and we'd cut a hotfix release that was immediately distributed to whoever it affects.

# ? Jan 3, 2013 20:31

b0lt: Apr 29, 2005

how!! posted:

why would you need to look through commit history to fix a bug? Just fix the bug. I've fixed many bugs, and can't tell you of a single time where I had to look through the history in order to fix it.

When I first started out, I used to do the long, thorough commit message every time. Until I realized its just wasted effort.

For example, if you want to find out which commit put your AWS keys in your public github repo so you can find out which commits you need to purge/how long it's been visible to the public.

git blame config.py

Python code:

672461b1 ([redacted] 2012-12-31 22:43:20 -0500 24) aws_access_key = 'AKIAJDBRZGUZ2PE334MQ'
672461b1 ([redacted] 2012-12-31 22:43:20 -0500 25) aws_secret_access_key = 'NZGwVHLrgxIJFz497lzQS9rR4cG8zMkR6mGjakcq'

git log 672461b1fa13450f680d75d20899a05dfcdc662c

code:

commit 672461b1fa13450f680d75d20899a05dfcdc662c
Author: [Redacted]
Date:   Mon Dec 31 22:43:20 2012 -0500

    initial commit

commit 9d466a40be9ab65b808983fd2a493c96cbf44681
Author: [Redacted]
Date:   Mon Dec 31 19:39:50 2012 -0800

    Initial commit

Oh.

# ? Jan 3, 2013 20:41

TOMSOVERBAGHDAD: Dec 26, 2004; Switzerland is small and neutral!

Couldn't some enterprising individual spin up a bunch of instances and cost someone a lot of money that way?

I sure hope that doesn't happen...

# ? Jan 3, 2013 20:46

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Bunny Cuddlin posted:

the change echos back and forth, forever, wasting hours and hours of dev and QA time.

Great, now you've given him something to masturbate to later

I wish I wasn't the only one who used commit messages where I work

# ? Jan 3, 2013 20:50

csammis: Aug 26, 2003; Mental Institution

b0lt posted:

For example, if you want to find out which commit put your AWS keys in your public github repo so you can find out which commits you need to purge/how long it's been visible to the public.

git blame config.py
Python code:
672461b1 (redacted) aws_access_key = 'AKIAJDBRZGUZ2PE334MQ'
672461b1 (redacted) aws_secret_access_key = 'NZGwVHLrgxIJFz497lzQS9rR4cG8zMkR6mGjakcq'
git log 672461b1fa13450f680d75d20899a05dfcdc662c
code:
commit 672461b1fa13450f680d75d20899a05dfcdc662c
Author: [Redacted]
Date:   Mon Dec 31 22:43:20 2012 -0500

    initial commit

commit 9d466a40be9ab65b808983fd2a493c96cbf44681
Author: [Redacted]
Date:   Mon Dec 31 19:39:50 2012 -0800

    Initial commit
Oh.

Nothing like a practical example :golfclap:

# ? Jan 3, 2013 20:51

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Bunny Cuddlin posted:

TFS allows easy linking/transitioning work items on commits too if you're in Microsoftland

TFS really is a wonderful product for those of us who are Microsoft-centric. I want to learn git better, but all of the commands are scary and obtuse.

# ? Jan 3, 2013 21:23

TOMSOVERBAGHDAD: Dec 26, 2004; Switzerland is small and neutral!

how!! makes changes to his repo, and doesn't even credit us for finding his security vulnerabilities. That's pretty damned rude, if you ask me.

# ? Jan 3, 2013 21:30

Bunny Cuddlin: Dec 12, 2004

lol at a mod editing his name out
it's on github, pretty sure it's meant to be public

# ? Jan 3, 2013 21:39

Catalyst-proof: May 11, 2011; better waste some time with you

Lol at the fact the AWS KEYS ARE STILL IN THE DIFF OF THE LATEST COMMIT. Learn how to use git.

# ? Jan 3, 2013 21:47

Bunny Cuddlin: Dec 12, 2004

how!! posted:

I'm not a CS guy. I'm self taught. The only problem I have as far as a programmer is passing interviews. I can write code better than anyone in this thread, as long as I have time to research solutions and think my way through. Yeah I guess that makes me cocky, but so be it.

TOTALLY SURPRISING. It's really fitting this happened in the horrors thread, because we're completely on topic too!

# ? Jan 3, 2013 21:51

Doctor w-rw-rw-: Jun 24, 2008

WHOIS John Galt posted:

Lol at the fact the AWS KEYS ARE STILL IN THE DIFF OF THE LATEST COMMIT. Learn how to use git.

He should filter-branch that history and push -f it. Sadly, the damage has probably been done.

# ? Jan 3, 2013 21:52

Catalyst-proof: May 11, 2011; better waste some time with you

Doctor w-rw-rw- posted:

He should filter-branch that history and push -f it. Sadly, the damage has probably been done.

Apparently 'preserving the integrity of the servers I pay money for' isn't a solution worth researching and thinking through. Now replace 'I' with 'my employer'.

# ? Jan 3, 2013 21:55

Bunny Cuddlin: Dec 12, 2004

Cocky Self-Taught Computer Programmer's Meticulously Crafted Github Resume Under Attack By Elitist CS Guy Illuminati

# ? Jan 3, 2013 21:55

b0lt: Apr 29, 2005

WHOIS John Galt posted:

Lol at the fact the AWS KEYS ARE STILL IN THE DIFF OF THE LATEST COMMIT. Learn how to use git.

The damage was already done, as long as the key is invalidated, it doesn't matter.

The true horror is this:

# ? Jan 3, 2013 22:00

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Wait until he blames git for keeping the history around and that means that the old keys are still there.

# ? Jan 3, 2013 22:03

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Thermopyle posted:

http://who-t.blogspot.com/2009/12/on-commit-messages.html

http://lists.cairographics.org/archives/cairo/2008-September/015092.html

# ? Jan 3, 2013 22:04

Bunny Cuddlin: Dec 12, 2004

Transprofessional Programmer Mercilessly Othered By Ciseducated Goon Squad

# ? Jan 3, 2013 22:04

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

b0lt posted:

The damage was already done, as long as the key is invalidated, it doesn't matter.

The true horror is this:

Oh, what? After all this, you really expected him to make a commit that *only* made changes relating to the commit message? "git commit -am" for life, rite guys?

# ? Jan 3, 2013 22:09

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

ultramiraculous posted:

Oh, what? After all this, you really expected him to make a commit that *only* made changes relating to the commit message? "git commit -am" for life, rite guys?

I think he redefined the debug module as the sort-of-built-in object True before trying to import it, but I'm not sure what order Django evaluates those files in.

# ? Jan 3, 2013 22:19

how!!: Nov 19, 2011; by angerbot

Munkeymon posted:

I think he redefined the debug module as the sort-of-built-in object True before trying to import it, but I'm not sure what order Django evaluates those files in.

``import debug`` is this: https://github.com/narfdotpl/debug

its a fancy way of doing ``from ipdb import set_trace; set_trace()`` plus is has some other things.

I spend my days writing code and fixing bugs. I don't sperg about pristine commit history.

# ? Jan 3, 2013 22:33

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

Deus Rex posted:

instead of deleting lines, comment them out and add a 2-3 sentence comment above explaining why it was deleted

Are you advocating this seriously, or are you ironically suggesting it and assuming it as implicit that it is bad practice? (This is not a sarcastic enquiry. I genuinely do not know.) If the latter, is it not appropriate to add a comment explaining why a particular approach is not used, if an alternate approach exists which might easily occur to someone reading the code but which has non-obvious deficiencies? (This need not involve including commented-out program code.)

# ? Jan 3, 2013 22:37

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

That's great. Please keep working by yourself where you don't understand the concept of tradeoffs or design decisions that you have to defend later, and please don't work on a team where you have to actually communicate about these things to other people, especially ours.

# ? Jan 3, 2013 22:37

b0lt: Apr 29, 2005

how!! posted:

I spend my days writing code and fixing bugs. I don't sperg about pristine commit history.

And yet

how!! posted:

So you're saying speed is all that matters? The advice is that I should not care about code being readable and elegant? A good programmer fixes everything in the quickest manner possible? If a problem can be fixed in 5 minutes, then spending 6 minutes is wasting time? I don't know, in my experience that line of thinking leads to really really complex code that becomes really unmaintainable really quickly. Its what I call "crap piled on top of crap, piled on top of crap, piled on top of crap"

elegant code == fun to work with (because you can easily run the code in your head)
complex code == not fun to work on (because you have no idea what the gently caress is going on)

not fun work == programmers procrastinate, get frustrated and make excuses for not getting the work done

how!! posted:

The way I measure 'goodness' of code is by the amount of time it would take to fix a bug if one were to emerge. Even my code could have a bug in it, but it would be faster to find in my code than yours. I'm biased though.

edit: your code doesn't strike me as terrible, but it doesn't strike me as awesome either. It just looks like code.
edit2: your code is almost half the lines as mine. That may be because mine has a bunch more documentation, but it could also be a sign that yours doesnt cover a corner case that mine does. tests would help determine this.

how!! posted:

You don't spend the extra time just to make it more extendable. You do it to make the code more understandable. Understandable code is not only more easily extendable, it is also more easily fixable and more easily changeable. Code is always broken and code is always in need of changing/improving.

Also, the act of refactoring code and making it more understandable will reveal bugs that you wouldn't have noticed.It also gives you ideas for features that would be easy to implement with the elegant code, which would have not been possible with the crappy code. For instance, my code makes it known when a domestic user gets matched up with someone from another country, or when an international user gets matched up with someone from the same country. That part of the program wasn't in the requirements, but it was trivial to implement so I went ahead and implemented it (mainly for my own testing purposes, if the boss wanted me to remove that code, I would). I don't know if baquerd's code can do that, but I imagine he would have to spend at least another half hour adding in that functionality if he was told to.

If the next person spends 8 hours changing the code, then that means they are completely changing the way the code behaves. If that were the case, then so be it, theres no way around it.

# ? Jan 3, 2013 22:51

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Commented-out code gets deleted on sight.

# ? Jan 3, 2013 22:58

Doctor w-rw-rw-: Jun 24, 2008

Just ignore how!! and be done with it. He's clearly trolling; don't let his shitposts derail the thread any further.

# ? Jan 3, 2013 23:01

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 21:07

Bunny Cuddlin: Dec 12, 2004

how!! posted:

I spend my days writing code and fixing bugs. I don't sperg about pristine commit history.

Go back to GBS.

# ? Jan 3, 2013 23:02

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »