If you've not looked at code, said who wrote this shit, then did a git blame and saw your name next to it, you've not really done serious programming.
Who wrote this shit?
251–260 of 300 posts
Re: Who wrote this shit?
#252Earlier quoted context omitted.
Sounds like an opportunity for someone to create an extension that replaces these words with somethingm that would be good for kids.
It's not as easy as you think: https://en.wikipedia.org/wiki/Scunthorpe_problem =)
Yeah, and sometimes you can lose meaning too. If I were implementing this, I would bleep out things like slurs, and words like 'shit' would be replaced with their (arbitrarily less crude) counterparts - 'crap' in this case.
There are existing software and methods to get around this problem of accidental censorship. Someone mentioned maintaining a professional vocabulary, and I am inclined to agree: The more you read people writing with crude language, the more likely you are to accidentally let it slip around your parents, or someone like a small child.
Anyway, on the subject of the actual post, comments are you and your future self's mutual friends.
Re: Who wrote this shit?
#253Earlier quoted context omitted.
I also had that moment; ask “Who wrote that shit?”, run ‘git blame’ and find yourself. This happened 1 year into my second job.
It sometimes can be misleading. If I'm refactoring large parts of code (e.g. splitting a large file to smaller ones), then sometimes the original logic written by someone else will be left, but git blame will show me because I was the last to make changes
git checkout BLAME_COMMIT~ && git blame should take care of that.
Re: Who wrote this shit?
#254On the topic of "who wrote this shit", I'd really like to plug the idea that some of the most high-impact documentation you can write is a good commit message. Say you track down a bug, find a line of code that makes no sense, and `git blame` it, to discover that you wrote it yourself, 2 years ago. If the commit message is "bugfix flaky builds", good luck figuring it out. If the commit subject rather, is "bugfix flak…
Code review discussions are precious context. Unfortunately, git does not keep them. This is a major shortcoming of git. We need a new source code management tool that stores code review comments. It can lower the cost of software maintenance.
Re: Who wrote this shit?
#255I once was challenged on who authored a game (Empire) that another was claiming to have written. The person who was judging this turned to a particularly messy section, and asked the other guy to explain it. He mumbled and stumbled. I could, and why it was so weird. The other guy caved and apologized.
Re: Who wrote this shit?
#256It was me ... several times I have found a bug or code smell and then been surprised that the I was the original author. For the last fifteen to twenty years, I've generally found looking at code I wrote six months ago equally distasteful. So now my default behavior is to assume the code met the business function at the time, acknowledge that I'm continuously improving in my craft and finally, gained a joy in spendin…
I was honestly surprised the author's answer was "my friend Torben" and not, "oh, it was me".
Part of the reason I like to write as little code as possible is that anything over a year old has some antipattern that I've come to loathe. I can't hate code that didn't get written in the first place.
Or at least, it's a lot harder to do so.
Re: Who wrote this shit?
#257Earlier quoted context omitted.
And sometimes the horrendous code really is written by someone else. I recently came across some horrendous code [1] that needlessly wrapped syslog(), and separated the format string from the point of use (the format string was a #define). The thing is---I know the developer (he left our company over a year ago) and is a great guy (former jazz musician), but let's just say he had some questionable coding practices. […
Could there be a reason to do that? E.g. preventing the format string from accidentally coming from untrusted user data?
Technically, a define is the same as hard-coding the string. Practically, at the point of use a define looks like a variable which might suggest it's ok to use another variable. Now it could take something from untrusted user input and you wouldn't notice.
Re: Who wrote this shit?
#258I've been dealing with legacy part of our app for the couple of days now, and I'm pissed.
But not at the code, I fully understand how code can become hairy, deadlines can be tight, etc. No. I'm pissed at my team (I'm new) who didn't have time in the past 5 years to even attempt to clean this shit up.
Re: Who wrote this shit?
#259Earlier quoted context omitted.
These two aren't mutually exclusive. Tickets, however, have lower long-term survivability (in my experience). Outsourcing, migrations, there are many scenarios in which the original tickets become inaccessible over time - and some codebases do last for years and years. Meanwhile the repository content (and thus the complete version history) usually survives as-is.
I didn't mean to imply they were mutually exclusive; just that in terms of "most high-impact documentation you can write", I find ensuring I link the ticket higher than making sure I have a thoughtful commit message, for the reasons listed. Fair that it can disappear eventually if you change ticket trackers or whatever; that's a risk of changing ticket trackers. Hopefully you maintain both for a bit, and once you're…
> But just in terms of "what would I rather have", a link to the ticket every time
In practice over the past 20+ years, I've had to rely on commit messages far more than tickets, but a well-written ticket is defnitely awesome to have. When I ran Engineering for a startup, one of the things we invested a lot of time in was making sure commits had good messages, tickets had good writeups, and the two were linked. We required a pull request to close a ticket, and our CI system would automatically append a link to the ticket to the PR when it was merged. It was such a level of awesomesauce.
Re: Who wrote this shit?
#260Earlier quoted context omitted.
And sometimes the horrendous code really is written by someone else. I recently came across some horrendous code [1] that needlessly wrapped syslog(), and separated the format string from the point of use (the format string was a #define). The thing is---I know the developer (he left our company over a year ago) and is a great guy (former jazz musician), but let's just say he had some questionable coding practices. […
Could there be a reason to do that? E.g. preventing the format string from accidentally coming from untrusted user data?
The only thing I could think of is a centralized location of all the format strings could make things easier to translate to another language. But as I stated in my post, it's an internal tool; we don't offer it to other customers as something to install, all our developers speak English, and there are other ways to mark strings for translation (at least on Linux, which this currently requires).